Method and device for synthesising an electrical architecture

ABSTRACT

A method of designing a hardware and software system specification. In the method services are defined and a use case is defined for each service; each use case is associated with at least one system start state, a user request and, for each start state, a system end state; operations are defined and, at the same time, a set of elementary operations is defined for each state, the set corresponding to the response from the system at the time of entry into the state; the architecture of the system is specified, defining electronic control units and networks; and elementary operations are placed on computers. Further, the method executes at least one of (1) identifying data flows circulating over the networks according to the placement or (2) identifying specification interfaces of the computers according to the placement.

The present invention relates to a method and a device for synthesizingan electrical architecture and to the applications of this method to avehicle, and in particular to a method and device for designing aspecification of a hardware and software system.

There now exist numerous methods and devices that treat, in isolatedmanner, the management of requirements, the specification of electronicfunctions, the design of electronic control calculators, the design ofelectronic messaging systems for on-board networks, and the design ofsoftware, although no method or device covers all of these aspects witha view to permitting rapid design of distributed hardware and softwaresystems.

The objective of the present invention is to provide an improved methodand device for synthesizing an electrical architecture and theapplications of this method to a vehicle, and in particular to providean improved method and device for designing a specification of ahardware and software system.

According to a first aspect, the present invention envisions a systemarchitecture design tool, characterized in that it comprises a pluralityof screens, which contain:

a hierarchical description of the system, at least one of the levels ofthe hierarchy representing services offered to users, and

when an element of the hierarchical description is selected, a syntheticview of at least part of the interface of this element with the rest ofthe system.

The present invention provides a method for designing a specification ofa hardware and software system, characterized in that it comprises:

a step of definition of services and, for each service, use cases;

a step of association of each use case with at least one departure stateof the system, a user request and, for each departure state, an arrivalstate of the system;

a step of definition of operations, in the course of which, for eachstate, there is defined a set of elementary operations corresponding tothe system response during arrival in the said/state;

a step of specification of system architecture defining electroniccontrol units and networks;

a step of mapping of elementary operations onto calculators; and atleast one of the following steps:

-   -   a step of identification of data flows circulating on the said        networks as a function of the said mapping; and    -   a step of identification of the specification of the calculator        interfaces as a function of the said mapping.

It will be appreciated that the design procedure may include productionof copies of data, such as data that may be read by a machine forautomatic implementation of a manufacturing step or system test, or by aperson to check such a system.

By virtue of these provisions, it is possible directly to take intoaccount the services offered to clients by accessing them in the saidscreens and observing synthetic views associated with these services. Itis recalled here that the services represent functions that benefit asystem user, such as the operator of a vehicle having the said system onboard. Services are defined by what the user wants (such as activationof the air conditioning, of windshield wipers) or by what is proposed tohim (such as passive safety, especially in the case of accidents). Theyare also defined by sensors and/or actuators that they activate. Theyeach correspond to a sensor/software/actuator hardware implementation,wherein the sensor can be hardware (instrument-panel sensors or pedals,for example). Starting from services, the design tool makes it possibleto determine system specifications, interfaces and the composition ofthe system elements and their communication with the other elements ofthe system.

According to particular characteristics, the tool contains a selectionmeans known as a “tab” and a hierarchical description, selection of eachtab causing a different screen of the tool to appear.

By virtue of these provisions, switching from one screen to the other isparticularly easy.

According to particular characteristics, for at least one screen, thehierarchical description represents, at a first level of hierarchy, aplurality of services and, at a second level of hierarchy, a pluralityof use cases for each service.

By virtue of these provisions, each service is defined by its use cases.For example, the “windshield wiper” service can be defined by use casesof intermittent wiping, of slow wiping and of fast wiping.

According to particular characteristics, for at least one said screen,each use case comprises an initial context or situation of the system, auser's request to the system and a response of the system correspondingto a change of its state.

By virtue of these provisions, information necessary to perform thetests of integration of the service will be available.

According to particular characteristics, in at least one screen, statesand associated state transitions are defined for each use case of aservice.

By virtue of each of these provisions, the use cases are formalized andin direct relationship with the system situations and states and thesystem user's requests that define the transitions between states.

According to particular characteristics, with at least one screen, thestates that function in modes transverse to common services are groupedin “phases”, each state is associated with one phase of the system, theset of formalized use cases representing all the responses or absencesof response of the system in all phases, these in total representing allcombinations of the modes of operation of the vehicle.

By virtue of these provisions, the states are arranged in a hierarchy,thus permitting better readability, because each phase then each phasetransition can be considered separately.

According to particular characteristics, each phase is composed of a setof combinations of modes of operation of the vehicle, the modes beingtransverse to the services and outside the direct control of theservices, such as a mode representing an available energy level and/or atype of system user and/or an accident or non-accident condition of avehicle.

By virtue of these provisions, the definition of phases is normalizedand implemented easily, and on the other hand it permits easy reading,because the states are arranged in a hierarchy.

According to particular characteristics, for at least one screen, thehierarchical description represents a plurality of services at a firstlevel of hierarchy and of phases of the service at a second level ofhierarchy.

By virtue of these provisions, the description of services is detailedfor each of the phases of the system, thus simplifying the work of thetool user.

According to particular characteristics, for at least one screen, thehierarchical description represents a plurality of services at a firstlevel of hierarchy and of states of the service at a second level ofhierarchy.

By virtue of these provisions, the description of services is attachedto states of the system, thus simplifying the work of the tool user.

According to particular characteristics, within the hierarchicaldescription, a hierarchical level in a given state describes theelementary operations.

By virtue of these provisions, the elementary operations effected by thesystem are accessible in the hierarchical description and can be editedby the tool user.

According to particular characteristics, for at least one screen, a usercan effect mapping of elementary operations onto components representedin a synthetic view.

By virtue of these provisions, the functional aspects of the system canbe installed, on the hardware components of this system.

According to particular characteristics, the tool contains, for at leastone screen, a synthetic view representing an envelope of a component andeach elementary operation that the said component controls or instructs.

By virtue of these provisions, the tool user can study the functioningof each component and the specifications that derive from it.

According to particular characteristics, the tool contains, for at leastone screen, a synthetic view representing an envelope of a service andeach elementary operation that the said service comprises.

By virtue of these provisions, the tool user can study the functioningof each service and the specifications that derive from it.

According to particular characteristics, for at least one screen, at afirst level of hierarchy, the hierarchical description represents thecalculators of the system and, at a second level of hierarchy,elementary operations electronically monitored or controlled by eachcalculator.

By virtue of these provisions, the tool user can study the functioningof each calculator and the specifications that derive from it.

According to particular characteristics, for at least one screen, asynthetic view represents, for each calculator, the services that aremapped at least partly onto the said calculator.

By virtue of these provisions, the tool user can study the relationshipsbetween the services and the calculators.

According to particular characteristics, for at least one screen, asynthetic view represents, for each calculator, the modes in which thesaid calculator must function.

By virtue of these provisions, the tool user can study the relationshipsbetween the modes and the calculators.

According to particular characteristics, for at least one screen, asynthetic view represents at least one network and the componentsconnected to it.

By virtue of these provisions, the tool user can study the functioningof each network.

According to particular characteristics, for at least one screen, at afirst level of hierarchy, the hierarchical description represents thecalculators of the system and, at a second level of hierarchy, for eachcalculator, the data frames being transported on the buses to which thecalculator and/or the electronic components (sensors, actuators)directly connected to the calculator are connected.

By virtue of these provisions, the tool user can study each calculatorand the interactions that it has with other elements of the system,especially the buses to which it is connected.

According to particular characteristics, for at least one screen, thehierarchical description represents the frames at a first level ofhierarchy and, at a second level of hierarchy, for each frame, the datacontained in the frames.

By virtue of these provisions, the tool user can detail the electronicmessaging system used and establish the relationships between the framesand the data that they contain.

According to particular characteristics, for at least one screen, asynthetic view represents components and/or networks and a projection ofa service onto the said components and/or networks.

By virtue of these provisions, the tool user can separately study eachservice in terms of hardware installation.

According to particular characteristics, for at least one screen, ahierarchical level describes, for each elementary operation, the inputand output interface data flows and, for each data flow, the driver andthe component and/or the elementary operation with which the data flowis exchanged.

By virtue of these provisions, the tool user can study the detail ofimplementation of an elementary operation in terms of data flows,drivers and/or components.

According to particular characteristics, for at least one screen, thehierarchical description represents, at a first level of hierarchy, aplurality of services and, at a second level of hierarchy, a pluralityof service variants, for each service.

By virtue of these provisions, the tool makes it possible to processdifferent service variants in the design of the architecture of asystem.

According to particular characteristics, for at least one screen, thehierarchical description represents, at a first level of hierarchy, aplurality of electronic components and, at a second level of hierarchy,a plurality of variants of electronic components, for each electroniccomponent.

By virtue of these provisions, the tool makes it possible to processdifferent component variants, for example different components ofdifferent equipment manufacturers, in the design of the architecture ofa system.

According to particular characteristics, for at least one syntheticview, a selection of an element of the synthetic view with a pointingdevice gives access to a representation of the functioning of the saidelement.

By virtue of these provisions, the tool user can study the functioningof different elements represented in the synthetic view.

According to particular characteristics, for a use case, given partialor complete mapping of the services, there is automatically identifiedthe set of elementary operations in the architecture as well as the setof data exchanged (frames, sensors, actuators) corresponding toexecution of the use case.

By virtue of these provisions, if an error is observed during anintegration test, or in other words for a given use case, the componentslikely to be the origin of the defect can be found.

According to particular characteristics, for a use case, if aperformance constraint is imposed on the said use case, there isautomatically identified the set of elementary operations in thearchitecture, the set of frames exchanged, the set of sensors necessaryand/or the set of actuators activated, in such a manner as to assignrespectively thereto the specific constraints of delay of execution, ofdelay of transmission or of delay of activation and/or to validate theconstraints already imposed.

By virtue of these provisions, it will be possible to decide theconstraints of refreshment of the different data exchanged by theelementary operations to which the performance constraint is applied.

According to a second aspect, the present invention envisions a methodfor synthesizing an electrical and electronic architecture of at leastone part of a product comprising electrical wires and electrical andelectronic components such as sensors, actuators and calculators,characterized in that it comprises the following steps:

-   -   the geometry of the product, divided into different zones, is        represented in two dimensions;    -   routing points for routing of electrical wires are mapped into        the different zones;    -   connecting points are mapped between the different zones;    -   the electrical and electronic components are mapped into the        zones;    -   a routing synthesis is undertaken as a function of the geometry        of the different zones and of the positions of the routing        points, of the connecting points and of the components;    -   an evaluation of this routing is undertaken and depending on the        result of this evaluation    -   the sites of the routing points, of connecting points and/or of        electrical and electronic components are modified and the steps        of synthesis and evaluation are repeated.

In the present invention, a 2-D topology is a result of the method.Also, according to the present invention, the pathways are generatedautomatically. By virtue of these provisions, the routing is optimizedby iteration.

According to particular characteristics, at least one connecting pointcorresponds, in the product, to one connector and/or at least onerouting point corresponds, in the product, to one connector.

By virtue of these provisions, the connectors are taken into account anddimensioned.

According to particular characteristics, there are defined in theinterior of the said zones prohibited subzones into which there must notbe mapped any wire, component or connector and, in the course of thesynthesis step, wires are not allowed to pass through a prohibitedsubzone.

By virtue of these provisions, the representation is more faithful andtakes into consideration the space requirement of certain product zones.

According to particular characteristics, before the electrical andelectronic components are mapped, at least one of the following choicesis made:

-   -   choice of electronic control units,    -   choice of communication networks,    -   choice of sensors and actuators,    -   choice of fuse and relay boxes,    -   choice of an electrical and electronic architecture.

According to particular characteristics, before the routing synthesis isundertaken, characteristics are specified for the electrical andelectronic components.

According to particular characteristics, after synthesis of the routing,the cabling composed of the synthesized routing and of connectors isvisually displayed.

By virtue of these provisions, the mapping of the routing points can beperfected by simplifying the geometry of the strands.

According to particular characteristics, the method contains a step ofvalidation of one routing among those evaluated, and calculation of atechnical specification is undertaken for the cabling composed of thevalidated synthesized routing and of connectors, and subsequently thereis undertaken the calculation of the technical specification, thecalculation of a cabling cost and/or the calculation of a qualitymeasure, for example by estimation of the number of breakdowns permillion and per year of the cabling.

By virtue of these provisions, the designer can compare differentarchitecture solutions and transmit the specification of the adoptedarchitecture to the development and perfecting team.

According to particular characteristics, the product is a vehicle andthe different zones of the vehicle contain at least one of the followingzones:

-   -   the zone of the front face,    -   the zone of the hood,    -   the zone of the instrument panel,    -   the zone of the roof,    -   the zone of the trunk and tailgate, above and below the        foregoing zones,    -   the zone of the right front fender and of the left front fender,    -   the zone of the right front door and of the left front door,    -   the zone of the right column and of the left column,    -   the zone of the right rear door and of the left rear door,    -   the zone of the right rear fender and of the left rear fender,        between the zone of the instrument panel and those of the right        front fender and of the left front fender, the zones of the        right front column and of the left front column, between the        zone of the trunk and those of the right rear fender and of the        left rear fender, the zones of the right rear column and of the        left rear column,    -   a zone above the floorboard and    -   a zone below the floorboard.

By virtue of these provisions, the method can be applied to a motorvehicle.

According to a third aspect, the present invention envisions a systemarchitecture design tool, characterized in that it is provided, forobjects, hardware components and/or services offered to the client, agraphic representation known as “envelope”, which contains:

a contour representing the said object,

representations of other objects with which the said objectcommunicates, and

representations of data exchanged with the said other objects.

By virtue of these provisions, the tool user has at his disposal asynthetic view of the interaction of the object with other objects ofthe system.

According to particular characteristics, when the said enveloperepresents a hardware component, data representations are effected for aservice.

By virtue of these provisions, each hardware-component/service pair canbe studied separately.

According to a fourth aspect, the present invention envisions a tool forrepresentation of the system comprising electronic components, eachconnected to at least one bus, characterized in that it contains, foreach bus, a representation of components that are connected directlythereto and, for components directly connected to at least two buses,for each of these buses, associated with the said component, anidentifier of each other bus to which the said component is directlyconnected.

By virtue of these provisions, the tool user has at his disposal athree-dimensional view, without complexity of representation, each busbeing represented in two dimensions and the links between the busesbeing represented according to a third dimension, by virtue of theidentifiers.

According to particular characteristics, the said identifier is agraphical element, for example a patch with a color identical to that ofthe bus in the said representation.

By virtue of these provisions, visual display of the relationshipsbetween the buses is easy, by virtue of the visual display of thegraphical element.

According to a fifth aspect, the present invention envisions a methodfor design of a specification of a hardware and software system,characterized in that it comprises:

a step of definition of services and, for each service, use cases;

a step of association of each use case with at least one departure stateof the system, a user request and, for each departure state, an arrivalstate of the system;

a step of definition of operations, in the course of which, for eachstate, there is defined a set of elementary operations corresponding tothe system response during arrival in the said state;

a step of specification of system architecture defining electroniccontrol units and networks;

a step of mapping of elementary operations onto calculators;

and at least one of the following steps:

a step of identification of data flows circulating on the said networksas a function of the said mapping; and

a step of identification of the specification of the calculatorinterfaces as a function of the said mapping.

By virtue of these provisions, this method makes it possible to startfrom services offered to the system user, to determine the functioningof the system then to install the elementary operations implementing theservices on calculators and to identify the consequences of theinstallation in terms of data flows and/or in terms of interfacespecification.

According to particular characteristics, the mapping step comprises, foreach service, a choice among a plurality of mapping modes comprising inparticular:

mapping of the service onto a single calculator,

master-slave mapping, in which a supplementary elementary operation ofcontrol of the single service activates, depending on the state of theservice in which the system finds itself, the elementary operations ofthe service, this supplementary elementary operation being mapped ontoone of the calculators,

distributed mapping, in which the elementary operations are distributedover at least two calculators and, onto each of the said calculators, asupplementary elementary operation of control of the service is mappedand activates, depending on the state of the service in which the systemfinds itself, the elementary operations of the service mapped onto thesaid calculators.

By virtue of these provisions, the mapping of each service can beeffected onto one or more components, with corresponding elementarycontrol operations.

According to particular characteristics, the supplementary elementaryoperations are generated automatically with:

as inputs, all data necessary for calculation of the transitions of thecontrol automaton of the service whose states are the states of theservice and the transitions are the transformations, via an elementaryoperation, of the user's requests and

as output, a datum representing the state in which the service findsitself.

By virtue of these provisions, the work of the tool user is greatlysimplified.

According to particular characteristics, in the course of the step ofidentification of data flows, a state of each data flow is determinedrelative to a given electronic messaging system:

“free” data, to be mapped into frames,

data already mapped into a frame and circulating on the network, andsuch that they are produced in the calculators in which the frame isproduced and consumed in the calculators in which the frame is consumed,and

unused frame sites.

By virtue of these provisions, the data and the frames can be organizedand, during design of the system, the work remaining to be done to coverthe entirety of data exchanges by the different frames can be measured.

According to particular characteristics, given a use case, a performanceconstraint is imposed on the use case as well as on certain of theelementary operations executed in the arrival state of the use case, thetool then automatically synthesizes the list of those executions ofelementary operations, executions of drivers, writes and reads in theframes, taking into account of information by sensors and actuators, andframe transfer to a, network that are implemented following mapping ofthe said elementary operations, and the designer can validate that thisperformance constraint is satisfied for a mapping of the said elementaryoperations or can specify requirements of delay of execution and/or ofresponse time to satisfy this performance constraint.

By virtue of these provisions, it is possible to ensure that the systemwill indeed have the expected performances and in particular it ispossible to perfect the performance requirements for the diversecomponents of the system

According to particular characteristics, if, for a service having atleast two variants, the said variants have shared elementary operations,then the said elementary operations are mapped onto the same calculatorsor calculator variants.

For example, variants of access to the vehicle, one by key, the otherkeyless, will share the elementary operations of locking and unlocking

By virtue of these provisions, it is possible simultaneously to managethe diversity of services during the mapping step, because there is noneed to effect the mapping of an elementary operation several times ifit is shared among several service variants.

According to a sixth aspect, the present invention envisions a tool fordesign of a cabling plan, characterized in that it comprises a pluralityof screens, each containing:

a hierarchical description of the hardware components to be mapped

a two-dimensional representation of the zones on which the componentsare mapped.

According to particular characteristics, the two-dimensionalrepresentation of the zones on which the components are mapped comprisesa global view of all of the zones as well as a means for adding orremoving zones.

According to particular characteristics, when a zone is selected in theglobal view of all zones, a local view of the zone appears, in whichlocal view geometric characteristics of the zone can be specified, forexample by clicking and dragging contour points of the zone.

By virtue of these provisions, the zone specification can be faithful tothe part that it represents.

According to particular characteristics, it is possible to edit on thelocal view of a zone routing points, connecting points, prohibitedsubzones and/or ground points by clicking and dragging an icon of thetool.

By virtue of these provisions, the designer can specify preferentialpoints of passage for routing of wires, which make it possible to formstrands, preferential points of passage from one zone to another andprohibited subzones in which, for mechanical- or space-requirementreasons, for example, no wire can pass the locations of the zone thatcan be used as ground.

According to particular characteristics, a routing point or a connectingpoint between zones can be transformed to a connector by clicking on anattribute of the said routing or connecting point.

By virtue of these provisions, it is possible to specify the siting ofconnectors, which will make it possible to divide the wires and strandsinto parts that are sufficiently small or practical for assembly.

According to particular characteristics, it is possible to specify thesiting of different electronic components, the fuse and relay boxes, theelectronic control units, the sensors and the actuators, particularlyby-clicking and dragging a representation of the said components in ahierarchical list.

By virtue of these provisions, the designer can specify the site atwhich these components will be mapped onto different zones of theproduct

According to particular characteristics, the routing of differentsensors and actuators up to the different fuse and relay boxes andelectronic control units is automatically synthesized.

By virtue of these provisions, it is possible to visually display thecabling and to perfect the positioning of routing and connecting pointsin order to reduce the lengths and shapes of strands “by sight”.

According to particular characteristics, for each sensor and eachactuator, there being specified data pins associated with drivers(hardware and software), themselves associated with data, power pinscorresponding to the supply and ground pins, the routing of wirescorresponding to these wires to the electronic control units or to thefuse and relay boxes for the data, to the fuse and relay boxes for thepower wires and to the closest grounds respectively is automaticallysynthesized.

By virtue of these provisions, there are evaluated the number ofconnector pins and connectors of electronic control units and fuse andrelay boxes, as well as the size of the different strands.

According to particular characteristics, if a sensor or an actuator isconnected to a calculator in the system architecture design tool, then,in the course of synthesis of the routing, the data pins of the saidsensor or of the said actuator are connected to the said calculator.

By virtue of these provisions, the requirements of linking of a sensoror of an actuator to a calculator, for example for contractual reasonswith a supplier, are taken into account in the design of the electricaland electronic architecture.

According to particular characteristics,

-   -   given a cost function of the connectors, for example based on a        nomogram that shows an estimate of the price of the connectors        as a function of the number of data, power and ground        connections, or based for example on a mean price assigned to        each connection of a data, current or ground wire,    -   given an evaluation of the cost of the electronic components,        sensors, actuators, electronic control units or fuse and relay        boxes    -   given a function of the cost of the wires based for example on        their length and type, taking for example a mean linear weight        for-the power and ground wires, a mean linear weight for the        data wires, and a cost per unit mass of the component in which        the said wires are manufactured,

there is automatically calculated a cost of an electrical and electronicarchitecture as a function of at least one of the said functions andevaluations.

By virtue of these provisions, it is possible to compare the respectivecosts of two architectures in order to choose the less expensive.

According to particular characteristics, given a mean cost for thesoftware and hardware drivers of the different drivers and given a costof implementation of an elementary operation, there is automaticallyestimated a cost of an electronic control unit or of a fuse and relaybox, then of a complete electrical and electronic architecture.

By virtue of these provisions, the cost estimate is automatic startingfrom any mapping whatsoever executed in the system architecture designtool of a plurality of services for which estimates were made.

According to particular characteristics, given a synthesized routing andgiven measures of quality for the connectors and the portions of wire ofdifferent zones, there is automatically estimated a measure of qualityof an electrical and electronic architecture.

By virtue of these provisions, it is possible to evaluate the respectivequality of two electrical architectures.

According to particular characteristics, given a measure of quality ofthe different calculators, sensors and actuators mapped into thedifferent zones, there is automatically estimated the quality of anelectrical and electronic architecture.

By virtue of these provisions, it is possible to evaluate the respectivequality of two electrical and electronic architectures.

According to particular characteristics,

-   -   given a measure of quality for each type of inputs/outputs and        for each type of wire (power, ground, data),    -   given a measure of quality for execution of an instruction on a        calculator, for access to random-access memory and for access to        flash memory,

there is automatically calculated a measure of quality for execution ofan elementary operation and for execution of a set of elementaryoperations on a calculator.

By virtue of these provisions, the quality of functioning of thecalculators in the quality evaluation of an electrical and electronicarchitecture is precisely taken into account.

According to particular characteristics, there is automaticallydetermined, in each zone, routing points that are candidates forgrouping the power and ground wires into splices, and there isautomatically chosen that which minimizes the wire length in the saidzone.

By virtue of these provisions, the cabling length is optimized and thesize of the connectors is minimized.

According to particular characteristics, splices are taken into accountin the cost and quality evaluations.

By virtue of these provisions, these evaluations are of better quality

According to a seventh aspect, the present invention envisions a toolfor synthesis of an economically optimal routing, characterized in that:

the different configurations of service variants and of calculatorvariants being specified and the percentage occurrence of theseconfigurations being known, the sum of the proportions of theconfigurations being equal to one,

the cost characteristics of the components being known and weighted as afunction of their respective installation proportions,

the partial or complete mapping of service variants onto the calculatorvariants being executed,

there is automatically synthesized an economically optimal routing suchthat, for each sensor and each actuator, the valid routings areidentified, the routing cost of the said valid routings is evaluated foreach configuration, and the valid routing that minimizes the mean,weighted by the installation proportions of each configuration and therouting costs for each configuration is chosen.

By virtue of these provisions, it is possible to compare the respectivecosts of two candidate architectures for a product plan by integrating amix of product lines and options.

According to particular characteristics, the routing of optimal qualityis synthesized, characterized in that the foregoing steps are repeated,the criterion for minimization being a measure of quality preferentiallyexpressed in breakdowns per million.

By virtue of these provisions, it is possible to compare the respectivemeasures of quality of two candidate architectures for a produced plan.

According to particular characteristics, the routing of optimal weightis synthesized, characterized in that the foregoing steps are repeated,the criterion for minimization being a measure of quality preferentiallyexpressed in breakdowns per million.

By virtue of these provisions, it is possible to compare the respectiveweights of two candidate architectures for a produced plan.

According to particular characteristics, there is automaticallycalculated a cost of assembly of the electrical and electronicarchitecture as a function of a cost of assembly of a strand on a zone,of a cost of assembly of a connector on a zone boundary or on a zone,of: a cost of assembly of a calculator on a zone, of a cost of assemblyof a sensor or actuator on a zone and of a cost of connection of aconnector between zones or in a zone.

By virtue of these provisions, it is possible to compare the respectiveassembly costs of two architectures.

According to particular characteristics, there is synthesized theoptimal routing for all configurations, by repeating the foregoingsteps, the criterion for minimization being ac cost composed of:

-   -   the estimated recurrent cost of parts,    -   an estimate of the quality cost in anticipation of the cost of        repair per zone, this cost being increased by a constant cost        depending on the zone and its ease of access,    -   an estimate of the cost of the weight, taking into account        mechanical wear and consumption related to an increase of the        weight of the vehicle, and/or    -   an estimate of the cost of assembly.

By virtue of these provisions, it is possible to execute an architecturethat optimizes the cost relative to a produced plan, and not onlyrelative to a single product variant, and taking all aspects of thedesign into account.

All operations of the method can be executed by means of a computer.

The method according to the invention can be applied to the synthesis ofthe electrical architecture of a newly created product. The methodaccording to the invention can also be applied to the synthesis of anelectrical architecture that has been modified relative to a previousarchitecture.

Other advantages, objectives and characteristics of the presentinvention will become evident from the description hereinafter withreference to the attached drawings, wherein:

FIG. 1 schematically represents the different steps of the methodaccording to the invention,

FIG. 2 is a view from above and in plan of the different zones of amotor vehicle,

FIG. 3 is a schematic view of elements of description of zones,

FIG. 4 shows validated routings in a door cutout zone of a vehicle,

FIG. 5 shows an example of the cabling of a vehicle door cutout,

FIGS. 6 to 16 represent screens used for the design of an electronic anddata-processing system architecture,

FIG. 17 represents steps implemented for specification of a servicevariant, and

FIG. 18 represents steps implemented in a method according to theinvention for design of a system architecture.

Before detailing particular embodiments of different aspects of thepresent invention, explanations of the terminology used are given here:

the terms “vehicle” and “product” are used without discrimination, thescope of the present invention not being limited to vehicles but theparticular embodiments being detailed for a product comprising avehicle.

the terms “estimate” and “evaluation” are used without discrimination.

for brevity, the term “tool” means “system architecture design tool”.

when, in the context of the description, the difference between anelectronic control unit or a fuse and relay box is not important, thedescription will refer simply to calculator. When management of thediversity of calculators is being discussed, the description will referto type of calculator for a generic calculator of an on-board network,such as the injection calculator of a motor vehicle, and to calculatorvariant for a particular instance of a type of calculator, for examplethis or that gasoline injection controller produced by this or thatequipment manufacturer, always for a motor vehicle. When on-boardnetworks are being discussed, the description will refer to network nodein order to mention a type of calculator or to a calculator variantdepending on the case, connected to a network, to remain consistent withthe traditionally employed terminology.

The notion of component will generally refer to a sensor or actuator, asopposed to a calculator. In contrast, an electronic component will benot only an actuator or a sensor but also a calculator or anotherintelligent component, which in English is also referred to as “smartcomponent”. An electrical-electronic component will designate any typeof component. In practice, these distinctions will be clear from the usecontext.

Finally, the description will refer simply to “response” in order toindicate a response to a user request.

FIG. 1 schematically represents the steps of the process followed toexecute routing of the wires of the electrical and electronicarchitecture as well as the evaluation thereof. Certain links betweencertain of the steps are symbolized therein by arrows. For example, thearrow between steps 102 and 104 indicates that step 104 is executedafter step 102. In contrast, there is no link between step 104 and step106, which two steps can be executed in any order desired withoutdetriment to the quality of the result.

To effect routing of the wires and evaluation thereof, the methodcomprises:

a step 102, in the course of which there is specified the geometry ofthe vehicle in the form of zones, for example by using a computer thatdisplays the screen illustrated in FIG. 13 and is provided with softwarewith which it can execute the functions described with regard to FIG.13; in parallel with this step 102, at least one of the followingchoices is made:

-   -   choice of electronic control units,    -   choice of communication networks,    -   choice of sensors and actuators,    -   choice of fuse and relay boxes,    -   choice of an electrical and electronic architecture    -   and the characteristics of the electrical and electronic        components are specified.

a step 104, in the course of which the “prohibited” subzones are mappedinto the zones described in the course of step 102, as explained withregard to FIGS. 13 and 14;

a step 106, in the course of which routing points and connectors aremapped, in particular between the zones defined in the course of step102;

a step 108, in the course of which the components are mapped;

a step 110, in the course of which the software that implements thefirst aspect of the present invention automatically effects a synthesisof the routing of the signals, an example of such a routing beingpresented in FIG. 5;

a step 112, in the course of which the software automatically effects asynthesis of the routing of the power, an example of such a routingbeing proposed in FIG. 5;

a step 114, in the course of which the software automatically effects asynthesis of the ground links, an example of such a routing beingproposed in FIG. 5;

a step 116, in the course of which the software automatically effects anevaluation of the costs of the routing, on the basis of functions forestimation of the costs of connectors and wires as a function of theirdimension and of functions for estimation of the costs of differentelectronic components and summing the costs of the elements composingthe architecture;

a step 118, in the course of which the software automatically effects anevaluation of the quality of the routing, on the basis of functions forestimation of the quality of connectors and wires as a function of theirdimension and of functions for estimation of the quality of differentelectronic components; and

a step 120, in the course of which the software automatically effects anevaluation of the weight of the routing, on the basis of functions forestimation of the weight of connectors and wires as a function of theirdimension and of functions for estimation of the weight of differentelectronic components.

Depending on the result of these evaluations, the sites of routing andconnecting points and of electrical and electronic components aremodified in steps 106 and 108 with a view to improvement, and thesynthesis steps 110, 112 and 114 are repeated to proceed with a newevaluation and converge iteratively to an optimized solution.

When an optimized solution is determined, calculation of a technicalspecification of the cabling composed of the validated synthesizedrouting and of connectors is undertaken.

FIG. 2 schematically represents the division into zones of a product, inthis case a 5-door motor vehicle with a tailgate. The different zones ofthe vehicle are represented in a view from above. These different zonescomprise: a right front fender zone 202, a right front door zone 204, aright column zone 206, a right rear door zone 208, a right rear fenderzone 210, a right front column zone 211, a right rear column zone 212, atailgate zone 214, a roof zone 216, a cockpit zone 218, a hood zone 220,a left front column zone 222, a right rear column zone 224, a front facezone 226, a left front fender zone 228, a left front door zone 230, aleft column zone 232, a right rear door zone 234, a left rear fenderzone 236 and a floorboard zone 240.

In FIG. 2, these zones are represented together and oriented accordingto a “compass” 238, included by way of indication, which permits theperson skilled in the art to navigate intuitively in each zone whileknowing how it is situated relative to those surrounding it, both in therepresentation and in reality. Compass 238 indicates how the zones aresituated relative to one another, but it does not apply to each zone inparticular, For example, “right front fender” zone 202 and “right frontdoor” zone 204 are positioned in such a way that it is possible todeduce therefrom that “right front fender” zone 202 is in front of“right front door” zone 204. Nevertheless, these two zones are verticaland, locally, will not be represented according to the orientationsindicated by “compass” 238.

Similarly, it is seen in FIG. 2 that “right column” zone 206 is at rightangles to “roof” zone 216, although “roof” zone 216 is horizontal andwill be represented in a local view according to the orientationsindicated by “compass” 238, whereas “right column” zone 206 is vertical.“Compass” 238 therefore serves to situate the zones relative to oneanother but does not necessarily apply to the description of thecontents of each zone.

FIG. 3 schematically represents zone description elements andillustrates how there are mapped, onto a “floorboard horizontal zone”318 corresponding in FIG. 2 to floorboard zone 240, a connecting point302, a routing point 312, a connector mapped instead and in place of arouting point 304 or instead and in place of a connecting point 316, aprohibited zone 314, and components 306 and 308, which are sensors,actuators, electronic control unit or fuse and relay boxes.

A zone routing is executed, component 306 being routed to connectingpoint 302 via connector 304 and component 308 being routed to connector316 via routing point 312. In addition, FIG. 3 illustrates theconnections between zones schematically indicated by the broken linebetween, on the one hand, connecting point 302 of floorboard horizontalzone 318 and connecting point 320 of contiguous vertical zone 324 and,on the other hand, connector 316 of floorboard horizontal zone 318 andconnector 322 of contiguous vertical zone 324. “Compass” 326 indicateshow to orient floorboard horizontal zone 318, while “compass” 328indicates how to orient contiguous vertical zone 324. It is noted thatthese two zones are perpendicular, floorboard horizontal zone 318 beinginscribed in a horizontal plane while contiguous vertical zone 328 isinscribed in a vertical plane. When connecting points 302 and 320 areassociated, they represent the same point in space, or in other words apoint of physical contact between floorboard horizontal zone 318 andcontiguous vertical zone 324. Similarly, connectors 312 and 316 areunited by a standard mechanism of “male/female coupling” type; forexample, connector 312 is a male connector and connector 316 is a femaleconnector, and these two connectors are physically linked at a physicalpoint of contact between floorboard horizontal zone 318 and contiguousvertical zone 324.

FIG. 4 schematically represents valid routings in a left front door zone414 corresponding to left front door zone 230 illustrated in FIG. 2.Prohibited subzones 418, 420 and 422 are shaded, and components arerepresented, in particular a window lifter control button 402, anilluminating light 404 of the window lifter control button, a lock motor406, a window lifter motor 408, and connectors 410 and 412. Reading ofzone 414 is simplified by means of “compass” 416. In addition, routingpoints 451, 452, 457 and 458 have been mapped. It is noted that certainvertices of prohibited subzone 422 are specifically useful for theroutings, or in other words electrical wires or links 454, 455 and 456.

FIG. 5 schematically represents a routing of a set of wires over twozones, on the one hand a left front door zone 414 and on the other handa cockpit zone 510. Certain components are common to FIGS. 4 and 5.Others, especially in cockpit zone 510, are added: a ground point 504,an electronic control unit 506, a fuse and relay box 508 and connectors502 and 512, corresponding respectively to connectors.410 and 412 ofleft front door zone 414. The links between the connectors of the twozones are symbolized by dotted lines in FIG. 5. In practice, connectors502 and 410, for example, are united by a standard mechanism of themale/female coupling type as indicated with regard to FIG. 3.

A two-dimensional representation of the product is achieved as follows:the product is divided into zones, whose dimensions must be specified,in order to conform as well as possible to the geometry of the productunder consideration. This representation is satisfactory in particularfor a motor vehicle, inasmuch as the cabling must be largely fixeddirectly to sheet metal panels and therefore to a decomposition of thevehicle into plane zones, as detailed in FIG. 2.

Each represented zone is preferably vertical or horizontal. For example,the floorboard of a vehicle can be associated with a horizontal zone anda door cutout of a vehicle can be associated with a vertical zone. Foran inclined tailgate, it is possible to choose one representation or theother. In addition, it is possible to indicate left and right, front andrear and top and bottom of the said zone. The objective of theseorientations is in particular that the person skilled in the art caneasily position himself in the transition from one zone to another, orfrom a global view in which all zones are represented to a local view inwhich a single zone, for example, is represented.

FIG. 2 represents a view from above of different zones of the upper partof a passenger compartment of a five-door (including the tailgate)automobile. The division into logical zones is specified, but therespective dimensions and shapes of the zones are not represented inFIG. 2. The zones are oriented in FIG. 2, since front, rear, left andright of the view from above are indicated. Certain parts such as theroof are horizontal, and others such as the doors are vertical.

Each zone can contain prohibited subzones, or in other words zonesthrough which wires cannot be passed. For example, the window in thetailgate of a vehicle will correspond to a prohibited subzone.

For reasons of simplicity, the zones can be represented by simplegeometric figures, such as polygons, or else more simply quadrilaterals.Each zone has its frame of reference and the prohibited subzones of azone. A are shapes inscribed in A, preferentially in the form ofpolygons or quadrilaterals.

FIG. 3 represents a zoom to a zone of the type of those described inFIG. 2. It is a zone inscribed in a horizontal plane, as indicated bycompass 328. It is labeled “floorboard horizontal zone”. At the centerof the part, a shaded shape indicates a prohibited subzone 314.Similarly, the shaded shapes in FIGS. 4 and 5 indicate prohibitedsubzones 418, 420 and 422.

In addition, each zone is linked to the other zones by connectingpoints, which serve to specify the geometric links between the differentzones and to specify sites where the wires can pass from one zone to theother. A connecting point between two zones is therefore represented oneach of these zones. A connecting point can be a connector. In thiscase, it is a connector on the two zones that it links.

In FIG. 3 there is illustrated the link between two zones via connectingpoints. “Floorboard horizontal zone” 318 is linked to “contiguousvertical zone” 324 by two connectors 302/320 and 316/322. These twoconnectors are situated at equal distance from one another on each ofthe said zones.

The routing points are points proposed by the designer for grouping ofwire in each zone, which make it possible in particular to group thewires in strands. Preferentially, all vertices of a prohibited subzoneare routing points, in order that a solution of the routing problemalways exists in a zone. By specification of the designer, a routingpoint can be a connector.

In FIG. 3, there are represented two routing points 304 and 312, one ofwhich, 304, is in fact a connector.

A routing between two points (for example, between a sensor and anactuator) is composed of a sequence of routing or connecting points. Thewire synthesized along a routing is imagined and represented as straightbetween two successive routing or connecting points.

A routing is said to be valid in a zone-if, on the one hand, it does notcross any prohibited subzone and if, on the other hand, given twosuccessive routing or connecting points A and B of the routing, thenthere does not exist a routing point C that can be reached withoutcrossing a prohibited subzone and such that the lengths of segments ACand BC are shorter than the length of segment AB.

A routing crossing several zones via connecting points between zones isvalid if it is valid in each zone.

The length of the routing of a wire is the sum of the distances betweenthe successive routing or connecting points forming the routing. Therouting is optimal if the routing length is minimal among all possiblevalid routings.

To find the optimal routing between two points, it is possible, forexample, to enumerate, all the valid routings that are possible betweenthese two points and that do not contain a loop (meaning that it neverpasses twice through the same routing or connecting point) and to,choose the shortest routing.

In FIG. 4, points 451, 452, 453, 454, 455, 456, 457 and 458 are routingpoints. Points 410 and 4-12 represent connecting points between zonescontaining connectors. It is noted that 454, 455 and 456 are alsovertices of a prohibited subzone. The possible routings for routing lockmotor 406 to connector 412 are numerous: there can be cited routings(406-451-452-458-412) and (406-454-455-456-457-458-412). In fact,routing (406-451-452-458-412) cannot be used, because it crosses aprohibited subzone. Finally, the shortest routing that meets allconditions is (406-454-455-456-458-412). In practice, the calculation ofa routing is performed between two components rather than between acomponent and a connecting point that may or may not comprise aconnector in a zone.

The electronic and electrical components that follow are mapped onto thedifferent product zones. These components are:

the electronic control units: these are electronic components capable ofcontrolling data signals; in other words, they are of low power andserve in particular to transport software data or data that can beinterpreted by the software, in particular originating from a sensor ordestined for an actuator;

the sensors and actuators;

the fuse and relay boxes: these are electronic components capable ofcontrolling not only low-power signals but also high-power signals,which are described simply as power signals;

the sources: these are energy sources, typically a battery—a source canbe regarded as equivalent to a particular fuse and relay box;

The electronic control units preferentially assure logical control ofthe components, while the boxes assure the relays of their supply andthe sources assure supply of the assembly. As their name indicates, thefuse and relay boxes contain, for example, fuses protecting thedifferent loads (energy-consuming components) positioned on thedifferent wires linked to the said boxes, and they also preferentiallycontain relays permitting activation of loads that require power.

Preferentially, the different elements of the electrical and electronicarchitecture are represented by points, or in other words are associatedwith two coordinates in the frame of reference of the zone into whichthey are mapped. The ground points are also mapped. The ground pointsare such that a ground wire, connected to a ground point, is at zeroelectrical potential. The ground points are specified by the designer.

The electrical and electronic architecture is given by:

the choice of electronic control units,

the choice of communication networks,

the choice of sensors and actuators,

the choice of fuse and relay boxes,

the logical links of these different components between one another.

These links are in particular the connections of the electronic controlunits and fuse and relay boxes to the different communication networks.These links may also be explicit links between a sensor or actuator andan electronic control unit or a fuse and relay box. In particular, sincea sensor, for example, can have a plurality of electrical links with itsenvironment, such as a ground link, a power link and a link forinformation transmission, the said sensor can be simultaneously linkedto ground, to a-fuse and relay box and to an electronic control unit.

The routing of the set of wires is executed in steps for a given mappingof the different elements of the architecture.

(A) The routing of a data signal from an input-output of a component toan input-output of an electronic control unit is achieved as follows:

(a) If the allocation of the data signal of the component (sensor oractuator) is specified, meaning that the electronic control unit towhich the component is linked for the said data signal has already beendefined, then the routing is optimal between the sensor and theelectronic control unit.

(b) If the allocation of the signal is not specified, then the componentis preferentially allocated to the closest electronic control unit, orin other words (i) the optimal routing Ci for joining the component tothe electronic control unit Calc_(i) is calculated by applying thepreceding step (a) and (ii) the shortest routing and the correspondingelectronic control unit or units are then selected, meaning Calc_(j)such that Cj=min Ci.

(B) The routing of a power signal of an input-output from a component toan input-output of a fuse and relay box is executed as follows:

(a) If the allocation of the power signal of the component (sensor oractuator) is specified, meaning that the fuse and relay box to which thecomponent is linked for the said power signal has already been defined,then the routing is optimal between the sensor and the fuse and relaybox.

(b) If the allocation Of the power signal is not specified, then thecomponent is preferentially allocated to the closest fuse and relay box,or in other words (i) the optimal routing Ci for joining the componentto the fuse and relay box Calc_(i) is calculated by applying thepreceding step (a) and (ii) the shortest routing and the correspondingfuse and relay box or boxes are then selected, meaning Calc_(j) suchthat Cj=min Ci.

(C) As regards the routing of a ground signal from an input-output of acomponent, this component being a sensor, an actuator, an electroniccontrol unit of a fuse and relay box,

the component is preferentially allocated to the closest ground point,or in other words (i) the optimal routing Ci for reaching each groundM_(i) is determined and (ii) the shortest routing or one of the shortestroutings M_(j) is then selected such that Cj=min Ci.

(D) Routing of a network between calculators

The topological characteristics of the network must be known: such anetwork is preferably organized as a star, line or ring depending on thecases.

For a controller area network (CAN), for example, the star or linetopologies are possible. Preferentially, the designer will indicate hisrecommendation. The reasons for choosing a topology are extremelyvaried. For example, the star network may be preferred for reasons ofoperating safety because, in the event that the bus is cut, only onecalculator is isolated, whereas, in the case of line topology, thenetwork is cut in two and the consequences are a priori more serious.

For a chosen topology, a search is then made for the routings thatminimize the distances between the calculators.

For a star topology:

(a) A contact point between the branches is chosen,

(b) A search is made for the optimal routing of this point with each ofthe electronic control units or each of the fuse and relay boxesconnected to the network,

(c) The sum of the lengths of the said optimal routings is calculated,

(d) The preceding three steps are applied for each of the existingcontact points and

(e) The contact point that minimizes the length of the network isselected.

For a line topology:

(a) A routing point permitting each electronic control unit or each fuseand relay box to be disconnected from the bus is chosen, the bus beingitself formed by the entire sequence of the said routing points that donot cut the prohibited subzone,

(b) The set of the said routing points permitting each electroniccontrol unit or each fuse and relay box to be connected to the bus whichminimizes the length of the network is determined, for example bysuccessive trials.

(E) Routing of a power signal of a calculator C.

This is treated as the routing of a power signal from a sensor to a fuseand relay box.

In FIG. 5, the zone “left front door zone” 414 and its connection with“cockpit extract zone” 512 are represented.

The complete routing of the different components of the said zones isexecuted. The components are first linked to electronic control unit UCE506. The different routings generated are therefore, by adopting thenotations used to describe FIG. 4:

motor 406 to UCE 506: (406-451-452-410-506),

motor 408 of the window lifter to UCE 506: (408-458-412-506),

control button 402 of the window lifter to UCE 506: (402-452-410-506),

light 404 of the control button of the window lifter to UCE 506:(404-452-410-506), and

from UCE 506 to fuse and relay box BFR 508: (506-508).

The electrical characteristics of the different components can bespecified: number of interface pins, nature of the pins (data, ground,power), allocation of data or power pins if they are specified, minimumoperating voltage, mean current, ringing current, consumed power; thisis done for each power wire leading out from the component.

The routing evolves consistently, since it is necessary to route eachwire separately and to specify a pin for each connector involved in therouting of a new wire.

In FIG. 5, motors 406 and 408 can each have three wires, for data, powerand ground respectively, and are therefore provided with three-pinconnectors. In this case, the links to ground M 504 and to fuse andrelay box BFR 508, which had not been expressed until now, appear in theform of new routings:

lock motor 406/pin 1 to UCE 506/pin 1 (data): (406/pin 1-451-452-410/pin1-506/pin 1),

window-lifter motor 408/pin 1 to UCE 506/pin 2 (data): (408/pin1-458-412/pin 1-506/pin 2),

lock motor 406/pin 2 to BFR 508/pin 1 (power): (406/pin 2-451-452-410pin 2-508/pin 1),

window-lifter L motor 408/pin 2 to BFR 508/pin 2 (power): (408/pin2-458-412/pin 2-508/pin 2),

lock motor 406/pin 3 to ground 504: (406-451-452-410/pin 3-504), and

window-lifter motor 408/pin 3 to ground 504: (408-458-412/pin 3-504).

The pins are not marked for a link to ground, because this ispreferentially a screwed connection or analogous means.

It is then possible to calculate the technical specification of thecabling composed of the following results:

the logical cabling plan: this is the description of the set of wiresegments necessary to execute the electrical and electronicarchitecture. Each wire links one pin of one connector of a component toone pin of another connector of another component and, in addition,passes through a certain number of routing and connecting points asspecified in the foregoing. The wire is logically defined by the datumof the two connectors and of the pins of each connector at the ends, orin other words at the level of the connected components, by the sequenceof routing points as well as by the sequence of connector pins, inparticular between zones being crossed. The logical cabling plan is thedatum of the set of logical definitions of the wires of which it iscomposed.

the specification of the connectors: for each connector, thespecification is composed of the number of connections corresponding todata wires, of the number of connections corresponding to power and ofthe number of connections corresponding to ground wires.

the specification of the interfaces of the electronic control units, ofthe fuse and relay boxes and of the sensors and actuators: it comprisesdescriptions of the connectors of these components, in the form of data,power and ground pins.

In FIG. 5, connector 410 now ensures five connections, of which threeare data, one is power and one is ground.

The user may also wish to calculate or evaluate the cost of anelectrical and electronic architecture, in particular to compare sucharchitectures and to choose the least costly with equal service andquality.

Given a function of cost of the connectors, for example based on anomogram that gives an estimate of the price of the connectors as afunction of the number of data, power and ground connections, or based,for example, on a mean price assigned to each connection of a data,current or ground wire;

given an evaluation of the cost of the electronic components, sensors,actuators, electronic control units or fuse and relay boxes;

given a function of cost of wires based, for example, on their lengthand on their type, by taking, for example, a mean linear weight for thepower and ground wires, a mean linear weight for the data wires and acost per unit weight of the component in which the said wires aremanufactured;

a cost evaluation for the electronic and electronic architecture underconsideration is automatically deduced from the technical, specificationby summing the costs of all the electronic components, of all theconnectors and of all the wires.

To estimate the cost of implementing an elementary operation, it ispossible, for example, to proceed as follows: given a number N ofassembler lines evaluated for each elementary operation mapped onto acalculator and an activation period P in seconds for each elementaryoperation, given a mean cost Cl for execution of an instruction persecond on a processor, given the memory space MEMO necessary for thedata that the elementary operation exchanges with the other elementaryoperations and the drivers; given an estimate of the cost CRAM of a RAMbit and an estimate CROM of a ROM bit or Cflash of a flash memory bit;given the number of bits of a word, or in other words the characteristicof being an n-bit (eight, sixteen or thirty-two, for example)microcontroller, the cost of an operation is:(N/P)*Cl+N*n*CROM+MEMO*n*CRAM.

On certain 32-bit microprocessors, certain instructions occupy 16 bits,which makes it possible in particular to save on memory. Thischaracteristic may be taken into account by separating these two typesof instructions if it is possible to evaluate a mix for the elementaryoperation under consideration, consuming half as much ROM for the 16-bitinstructions.

It is to be noted that the cost Cl of execution of one instruction persecond on a processor may depend on the type of application beingprocessed, since not all instructions take place in just as many cycles.For example, on a twenty MIPS (million instructions per second)processor, it is possible to achieve twenty million instructions for onecycle in one second, but only one million instructions for twentycycles. Thus this evaluation is stipulated according to the mean numberof cycles per instruction necessary for each type of application.

It is important to note that the mean cost of an instruction, of a RAMbit and of a flash bit on a microcontroller may, for example, beextrapolated from the observation of at least three microcontrollers (i)for which the cost (C_(i)) and the RAM (R_(i)), MIPS (M_(i)) and flashmemory (F_(i)) characteristics and the number (n_(i)) of bits in a wordare known. In fact, for each-microcontroller, there is established theequation in the unknowns Cl, CRAM, Cflash: andCl*M _(i) +CRAM*n _(i) *R _(i) +Cflash*n _(i) *F _(i)=C_(i)

Such a system of three equations has a unique solution, the differentconstants being non-zero. When numerous controllers are examined, thisestimate can of course be refined.

It is to be noted that, if the elementary operation is the controlautomaton of a service, then the estimate of the number of lines of codeis determined as a function of the number of states and of the number oftransitions, and the activation period is determined as a function ofthe performance requirements on the different use cases.

In addition, the cost of the different hardware drivers can be evaluatedas a function of their type (all-or-nothing, analog-digital, etc.) andof their electrical characteristics.

The user may also wish to evaluate the quality of an electrical andelectronic architecture, in particular to compare such architectures andto choose that which presents the best quality level for identicalservice and cost.

The measure of quality is preferentially obtained by measuring thenumber of failures per million units per year of the entirety of thearchitecture, preferentially by means of a software routine.

To calculate this number

the software measures the quality of the set of connectors, whether theyare connectors between zones or within zones or input/output connectorsof the electronic components (sensors, actuators, electronic controlunits, fuse and relay boxes) by assigning, for example, a mean failurerate per connection, such as 10 ppm (failure per million units per year)and by multiplying this mean rate by the total number of connections inthe system. To obtain a more precise evaluation, the software takes intoaccount the means adjusted as a function of the type of connection:ground, power and data, the finest wires being the most fragile. Forexample, 4 ppm per connection is taken for power or ground wires on apin and 6 ppm per connection is taken for data wires on a pin and,finally, an estimate of 4 ppm is used per portion of data wire betweentwo connectors. In this case, by referring to FIG. 5 and the detail ofthe connections and wires presented in the description of FIG. 5, thefollowing evaluation can be achieved for each section:

lock motor 406/pin 1 to UCE 506/pin 1 (data): (406/pin 1-451-452-410/pin1-506/pin 1): 3*6 ppm+2*4 ppm, or in other words 26 ppm

window-lifter motor 408/pin 1 to UCE 506/pin 2 (data): (408/pin1-458-412/pin 1--506/pin 2): 3*6 ppm+2*4 ppm, or in other words 26 ppm

lock motor 406/pin 2 to BFR 508/pin 1 (power): (406/pin2-451-452-410/pin 2-508/pin 1): 3*4 ppm, or in other words 12 ppm

window-lifter L motor 408/pin 2 to BFR 508/pin 2 (power): (408/pin2-458-412/pin 2-508/pin 2): 3*4 ppm, or in other words 12 ppm

lock motor 406/pin 3 to ground 504: (406-451-452-410/pin 3-504), or inother words 3*4 ppm

motor of window lifter 408/pin 3 to ground 504: (408-458-412/pin 3-504),or in other words 3*4 ppm

for a total of 100 ppm

If a splice at 452 is now taken into account, then the ppm correspondingto the duplication of wires after the splice, in view of actuators.406and 408, can be eliminated, or in other words 3*4 ppm. By taking a powersplice into account, 88 ppm is found as the quality of the optimizedrouting. By taking a ground splice at the same routing point intoaccount, it is possible to save another 12 ppm, thus ending with 76 ppm.Optimization over a cost estimate would consist, in similar manner ofeliminating the cost of the portions of wires and connector pinseliminated by virtue of the splice.

The tool measures the quality of the electronic components that isspecified in a component database and that can be described as afunction of the type of component or specifically for each component;for example, an evaluation of 100 ppm can be attached to all electroniccontrol units.

The tool then adds the measurements of all components constituting theelectrical and electronic architecture.

The user can also refine the routing strategy by integrating splices forthe power wires and the ground wires. These splices can be used at thelevel of connectors or within a zone, preferentially at the level of arouting point.

Creating a ground splice consists in joining all (n) ground wirespassing through a point, and in particular through a connecting point ora routing point. In this way, by working up to the closest ground,savings are achieved on the one hand in wires and on the other hand inconnecting pins corresponding to the (n−1) wires removed.

Creating a power splice consists in joining the power wires that, on theone hand, pass through a common point, in particular through aconnecting point or a routing point, and that, on the other hand, jointhe loads at a common fuse and relay box. For example, in FIG. 5, thesupply wire of lock motor 406 and the supply wire of light 404 can bejoined at the level of routing point 452 or else at the level ofconnector 410. Such splices serve to save on pins at the level of theconnectors and the portions of wire eliminated in this way. Thus it issought to minimize the length of the wires, and it will be chosen tocreate the splice at routing point 452 in order to save on the lengthsof wire between 452 and 410. Point 452 is that which minimizes thelengths of wire for creation of the splice in the example of FIG. 5.

Creating a splice at the level of a connector is equivalent to linking,to one another, the connector pins corresponding to the wires that arewished to be joined.

The synthesis of the routing can then be improved by searching todetermine whether one or more splices of ground wires or of power wireswould permit the global cost of the architecture to be minimized. Forthat purpose it is necessary to input new data into the cost base of theunit components, in particular the cost of a splice as a function of thenumber of wires joined and the cost of a splice at the level of aconnector as a function of the number of wires joined.

FIG. 6 and the following figures describe a system architecture designtool and a method for designing a specification of a hardware andsoftware system by using this tool.

This tool is particularly suitable for cases of complex systemscomprising a set of calculators that execute numerous services for thebenefit of a user, each service presenting numerous use cases. Forexample, the electronic and data-processing systems of vehicles areparticularly envisioned by this tool.

Services are defined by what the user wants (for example, activation ofthe air conditioning, of windshield wipers) or by what is proposed tohim (such as passive safety, especially in the case of accidents). Theyare also defined by sensors and/or actuators that they activate. Theyeach correspond to a hardware implementation in the form ofsensor/software/actuator. The maker has room to maneuver within thedefinition of the internal architecture of theelectronic/data-processing system, especially in the choice of on-boardnetworks and of electronic boxes connected to these networks, and thedesign tool presented here makes it possible to design thisarchitecture.

Starting from services, the design tool makes it possible to determinespecifications rather than finished products. Nevertheless, this toolalso determines the interfaces and the composition of the elements andtheir communication with the electronic/data-processing system.

In particular, this tool does not envision programming the calculatorsautomatically, but managing cost/quality/time compromises for thespecified system.

The design tool is implemented in the form of a software routine runningon a personal computer and using a database and known resources(operating system and distribution on the network).

According to one aspect of the present invention:

each service represents a function performed for a user,

a set of formalized use cases of each service is defined, eachformalized use case comprising a context of origin, a user request,which may be implicit, and a system response corresponding to a changeof its state, and

the system is organized and specified to effect the response, when itdetects that the request has been sent in the context of origin.

With this objective, according to one aspect of the present invention,the method comprises a step of design, for each service, of a controlautomaton of the service that is intended to be implemented by thesystem of hardware and software components and that represents thebehavior of this system. This design step comprises, for each service, astep of definition of a formalized use case of the service, specified bya context, a user request to the system and a system responsecorresponding to a change of its state and, in iterative manner, untilall use cases of the service have been treated:

a step of addition of a formalized use case of the service, specified byan initial context or situation of the system, a user request to thesystem and a system response corresponding to a change of its state,

and, in iterative manner, for each already constructed state, theprogram searches whether it is compatible with the context of the addedformalized use case and, if yes, there is constructed a new system stateconnected to the said state already constructed by the request of theadded formalized use case, the new state taking into account the alreadyconstructed state and its modification by the response of the addedformalized use case.

In this way, there is synthesized, for the service, the controlautomaton of the service that is composed of the set of pairs of statesconnected by the requests forming the transitions of the said automaton.

The context represents at least one mode (or parameter) of operation ofthe system, the modes being transverse to the services and beyond thedirect control of the services, for example a mode representing anavailable energy level (low battery, on battery, in course of starting,engine turning, for example), another mode representing a type of systemuser (designer, manufacturer, vehicle owner, vehicle operator orpassenger, after-sales service, automobile repair shop, for example) andanother mode representing an accident or non-accident state of avehicle. It must be noted that, although starting the engine is one ofthe services of the vehicle, the change of available energy level(linked to driving of the alternator by the engine) is not directlyunder the control of this service.

In the embodiment described here, every context fits into a life phaseof the system composed of a set of combinations of modes of operation ofthe vehicle, the declination in mode of the phases thus being transverseto the services. Ultimately a context will correspond to a set of pairs(phase, system state), each state being in fact characterized by theresponse of the system when it is accessed.

For example, the use case “in the context in which the vehicle islatched, the user presses his unlatching badge and the vehicle becomesunlatched” is applied to the states “vehicle locked” in the phases“engine running” and “engine stopped”, if these two phases have beenidentified as pertinent by other formalized use cases of the “unlocking”service. Each phase corresponds to a set of combinations of modes inwhich the behavior of the service is uniform, meaning in which the samestates and the same client requests are observed, or in other words thesame client requests and the same system responses starting from a givenstate.

The table below defines a set of phases for a given vehicle. ENERGY USERVEHICLE STATE PHASE battery low designer vehicle not in accident statephase 1 battery low designer vehicle in accident state phase 2 batterylow manufacturer vehicle not in accident state phase 1 battery lowmanufacturer vehicle in accident state phase 2 battery low owner vehiclenot in accident state phase 3 battery low owner vehicle in accidentstate phase 2 battery low operator vehicle not in accident state phase 1battery low operator vehicle in accident state phase 2 battery lowafter-sales service vehicle not in accident state phase 4 battery lowafter-sales service vehicle in accident state phase 5 battery low repairshop vehicle not in accident state phase 4 battery low repair shopvehicle in accident state phase 5 battery normal designer vehicle not inaccident state phase 6 battery normal designer vehicle in accident statephase 2 battery normal manufacturer vehicle not in accident state phase6 battery normal manufacturer vehicle in accident state phase 2 batterynormal owner vehicle not in accident state phase 7 battery normal ownervehicle in accident state phase 2 battery normal operator vehicle not inaccident state phase 6 battery normal operator vehicle in accident statephase 2 battery normal after-sales service vehicle not in accident statephase 4 battery normal after-sales service vehicle in accident statephase 5 battery normal repair shop vehicle not in accident state phase 4battery normal repair shop vehicle in accident state phase 5 startingdesigner vehicle not in accident state phase 8 starting designer vehiclein accident state phase 9

In this table, all triplets of modes of operation are placed incorrespondence with phases, each phase representing a set ofcombinations of possible values of modes of operation. If the behaviorof the vehicle is always the same, a single phase is defined in thetable, otherwise several phases are differentiated.

The set of formalized use cases represents all responses or absences ofresponse of the system in all phases of the system.

The tool permits a step of supplementation, in the course of which, foreach response, or in other words a state of the system, all clientrequests that have not yet been processed are envisioned and thedesigner is asked if processing of the request must be effected in thestate corresponding to this request. Only the client requests can havean action on the service.

The design tool also permits a correction step in the course of which,if, in a same departure step, two states of the control automaton of theservice are connected by different requests, then the necessity ofdefining a priority among the system responses is determined and thispriority is incorporated as an attribute of the outputs of the state.Priority information typically comes after design of the formalized usecases. It is possible, for mechanical or other reasons, that twopotentially concurrent requests can in fact never be honoredsimultaneously. In this case it is necessary to wait for a more advanceddesign step to be certain that it is not necessary to specify apriority, unless this can be guaranteed directly (example: opening adoor and closing the same door cannot be achieved simultaneously). Inaddition, if two identical requests lead to different states, anincompatibility must be corrected and one of the requests must besuppressed and consequently the corresponding use case must beclarified.

It is observed that a change of context is taken into account by thesystem in the following manner:

each change of context is a change of state that is the object of aformalized use case (CUF);

the responses to changes of context are defined as formalized use cases;

changes of context are defined as requests of formalized use cases.

If one service influences another (for example, the same indicator isshared by two services, such as the automatic radio and navigationsystem), a service is added for the overlapping portion, in such a wayas to resolve the conflicts between the services. The objective of thisservice will be to arbitrate, when two concurrent actions are beingapplied to a given component by two services, which of the services haspriority or if a specific action corresponding to this particular casemust be taken. Such a service is typically specified not on the basis ofuse cases but instead by identification of the states of two services inwhich the reactions leading to conflict (relative to one or more givencomponents) are identified.

The control automaton of the service is achieved by programming at leastone control calculator of the corresponding service.

The tool comprises different pages accessible by clicking on tabs. Thesepages are described with regard to FIGS. 6 to 16. For clarity, the tabtitles and elements of lists selected by the designer are underlined andbolded in FIGS. 6 to 16.

As illustrated in FIG. 6, user interface 600 of this software toolcomprises:

drop-down menus 601 to 608,

six horizontal tabs 611 to 616,

a hierarchical list zone 620 and

a graphical zone 630.

Drop-down menus 601 to 608 are represented by their titles “File”,“Edit”, “View”, “Dictionaries”, “Windows”, “Tools”, “Import/Export” and“Help”. By clicking on one of these titles with the left button of themouse, a drop-down menu appears with options participating inimplementation of the method (open, edit, save, close file, cut, copy,paste selected elements, view modes, glossary, tools, import or exportfiles, help, etc.). While he is working on the design of an electronicand data-processing system architecture for a vehicle, the designer doesnot necessarily have to use these drop-down menus 601 to 608.

Regardless of the tab selected from among tabs 611 to 616, the designtool shows a screen comprising a hierarchical list part (at the left inFIGS. 6 to 16) representing a hierarchical description and a graphicalpart (at the right in FIGS. 6 to 16) giving, as a function of aselection, by means of a pointing device (in the rest of thedescription, a mouse), of an element of the hierarchical list, asynthetic view concerning the selected element.

It is important to note here that, for at least one user interface ofthe design tool, or in other words for at least one tab, a hierarchicallevel of the hierarchical list represents services. In the embodimentillustrated in the figures, the first three tabs 611 to 613 present thischaracteristic.

Using a mouse (not illustrated), the user can make “pop-up” menus appearin one of the list or graphical zones by clicking on one of the left orright buttons of the mouse.

To design the architecture and the specifications of the system, theuser successively selects horizontal tabs 611 to 616 by clicking above,knowing that one of the properties of the design tool is that the usercan select the tabs in any order that he wishes.

The horizontal tabs have the following titles:

“Requirements”, tab 611,

“Feature description”, tab 612,

“Feature architecture”, tab 613,

“Operational architecture”, tab 614,

“Hardware architecture”, tab 615,

“Frame description”, tab 616.

These tabs represent, in this order, several steps of the method that isthe object of the present invention:

These titles appear in full when the corresponding tabs are selected andin abbreviated form (“REQ” 611, “FUNC” 612, “MAP” 613, “OPER” 614, “HWD”615 and “MSG” 616, respectively) the rest of the time.

To design the architecture of a system, the designer first selects tab611 “Requirements” and sees the screen illustrated in FIG. 6. At theleft there is seen hierarchical list zone 620, which contains part of alist in which the five highest levels of hierarchy are as follows:

vehicle name

-   -   services        -   service variants            -   use cases                -   link between states

As is known in the art of file finding in an individual computerenvironment, for example of the PC type, the elements of lowerhierarchical level may or may not be visible. For example, when the listapparently contains only vehicle names, by clicking with the left buttonof the mouse on a vehicle name, the list of services proposed for thisvehicle will appear. By selecting a service, the list of servicevariants relating thereto is made to appear and so on.

By clicking with the right button of the mouse on a displayed element,it is possible to edit the list of immediately lower hierarchy, or inother words to add, modify or delete a use case by clicking on a usevariant, for example. This editing is accomplished by means of a menuthat pops up on being clicked and that contains, for example, theoptions “add”, “remove”, “properties” and “show differences” (an optionmaking it possible to compare two elements of the same hierarchicallevel, including those on two different vehicles).

In the design tool, a use case is defined by an initial phase (such asan available energy level) that is transverse relative to the vehicle,an initial state (such as the position of actuators), a demand orrequest, a final phase and a final state.

For example, in the “access” service, which concerns the openings of thevehicle, there is added a new use case (CU) concerning what must be donefollowing a serious accident. For this new use case, there is defined aname “after a crash” and a text description “regardless of the initialcontext of the vehicle, the ignition being on, if a crash is detected,then all accesses must be unlatched”. The name and description arecalled “properties” of the new use case.

FIG. 6 represents the interface when the use case “User opens trunk” isselected.

When an element of the hierarchical list is selected by left clickingwith the mouse, a synthetic representation of this element is seen ingraphical part 630.

Depending on the level of the selected element of the hierarchical list,there can be seen in graphical zone 630: vehicle name: the list ofservices services: the list of service variants service variants: thelist of use cases use case: the different embodiments of the use case bya set of state transitions in the different phases of the service.Incidentally, this is the selection that is presented in graphical part630 link between performance requirements relative to the differentstates: elementary operations that are achieved in the arrival state(see example described above).

For example, by left clicking on a service variant, there is displayedin the graphical part a list of use cases together with theirdescription in a text, each paragraph corresponding to a use case. Byleft clicking on a formalized use case, there is displayed, in verticalsuccession and under headers 650 and 651 indicating the phases inquestion, “phase 1” and “phase 2”, initial states 660 to 663 andterminal states 664 to 667, represented by rectangles and connected bylinks 668 to 671. On these links there appears the name of the clientrequest that causes the change from the initial state to the finalstate.

It is seen that, to make a use case “formalized”, the use case isselected by right clicking and, in the pop-up menu, choosing “linkdefinition” to put links in place, each link being defined in one phaseand between two states of the vehicle (such as “doors closed, trunkclosed” and “doors closed, trunk closed, one door open”). To this end, acontextual menu contains four zones, “initial phase”, “initial state”,“final phase” and “final state”, which make it possible to select, amongall already defined phases or among all already defined states, thosewhich represent the use case. With this contextual menu, and by virtueof buttons, it is possible to add states and phases in the proposedlists of states and phases. In working to define a use case, there areadded phases that are specific to the service in question, while themodes are for all services.

For example, the “brake” service contains four phases:

emergency braking,

braking,

brake failure and

normal brake operation (“brake nominal phase”).

For example, for the “air-conditioning” service, two phases are defined,one for low available energy levels, for which ventilation is effectedwithout cooling of the ventilated air, too energy-consuming, and theother for the case of engine running, the air-conditioning beingeffected with cooling of the ventilated air.

The operating algorithm of a service is represented by rectangularblocks, representing states, and by arrows, representing an action orabsence of action that causes a transition between states. Byconvention, the arrows leading out from one state exit the blockrepresenting that state at one of its right or left vertical faces,while the arrows reach the states at one of the upper or lowerhorizontal faces-of the corresponding block.

A transition represents a client request. For example, clicking on anopen-trunk badge causes a change from the “all closed” state, in whichall openings of the vehicle are closed, to a “doors closed/trunk open”state. For each state, there is defined in this way a set of elementaryoperations that must function or be executed in the said state. The setof states and transitions forms a control automaton associated with theservice.

It is evident that the states can be regarded as “client feelings”, thetransitions being the requests of the client, which may be implicit. Itis understood that the phases are attributes of the states, although twostates that are identical except for their phases (phases “beforeignition” and “after ignition”, for example) are considered as twoindependent states.

It is also evident that the vehicle cannot be in two statessimultaneously for the same service and that, if two services are notindependent (such as automatic radio and guidance system using the sameindicator), there is added an arbitration service, invoked on request ofat least one of the services in question, which will determine how thesystem will behave when the two services are using the same resources.

For example, to describe a link definition whose logic is:

“regardless of the initial context of the vehicle, the ignition beingon, if a crash is detected, then all accesses must be unlatched”, thenif the doors have already been unlatched it is not necessary to unlatchthem;

there is selected the phase “ignition on” and the initial state “vehiclelatched by the passenger-compartment button” and there is selected thelink to the final state “emergency unlatch” passing through thetransition or request “crash detected”. This is repeated for all initialstates except “all openings open” and only for the phase “ignition on”.

As soon as a link has been added and validated, a graphic appears in theright part: two rectangles, above which there appear the names of theirrespective phases (“ignition on” and “crash”) and a curved link, withthe name of the transition under the link. The use case then becomes aformalized use case (“CUF”).

When a state is added with regard to a new use case, it is necessary tocheck whether it is useful in the other use cases.

For example, if the “childproof latch” use case is added, making itpossible to prevent children from being able to open the rear doors, itis necessary to add the corresponding state in the description of the“crash” use case.

By processing all the use cases of all the variants of a given service,there has been created a control automaton of the service that appearsin graphical zone 630 when the service is selected after the “FUNC” tabhas been clicked.

When the “Requirements” tab is selected, as illustrated in FIG. 6, novertical tab appears at the side in graphical zone 630.

The designer then selects the “FUNC” or “feature description” tab. FIG.7 illustrates an image of the user interface that is then displayed onthe screen of the design station.

In FIG. 7, user interface 700 of this software tool then comprises:

drop-down menus 601 to 608,

six horizontal tabs 611 to 616,

a hierarchical list zone 720,

a graphical zone 730, and

vertical tabs 731 and 732.

Vertical tabs 731 and 732 are respectively named “functional diagram”and “feature” and are attached to graphical zone 730. They are used toselect a content to be displayed in this graphical zone 730, asexplained hereinafter.

At the left, hierarchical list 720 contains part of the list in whichthe ten highest levels of hierarchy are as follows:

-   vehicle name    -   services        -   service variants            -   phase                -   state                -    group of elementary operations                -     elementary operation                -      datum                -       driver                -        component.

The highest three levels of hierarchy are identical to those of list 620and in particular contain the services. Selection of one of thecomponents of the hierarchical list by left clicking causes, togetherwith the “feature” tab 732 selected, the set of elements of the list ofimmediately lower level to appear in graphical part 730, sometimes witha control flow between the components if the mouse is used to point toand click on a service variant (the phases appear in the left partlinked to one another by client requests corresponding to phasetransitions) or on a phase (the phase states appear in the left part,linked to one another by the “client requests”).

When an item in hierarchical list 720 is clicked on with the rightbutton, the tool makes it possible in particular to add or removeelements in the hierarchical level immediately below. By clicking on oneof the items phase, state or group of elementary operations, it is alsopossible to add an elementary operation transversely in respectively thesaid phase, or in other words in the set of states of the said phase,while indicating in which group of elementary operations the saidelementary operation is being added, in the said state, in particularindicating in which group of elementary operations the said elementaryoperation in the said state is being added, and in the said group ofelementary operations. By right clicking on the phase item ofhierarchical list 720, it is possible to add a phase transition, inwhich case the tool asks for the arrival phase, the client requestcorresponding to the transition and the departure and arrival states forthe phase transition. By right clicking on the state item ofhierarchical list 720, it is possible to add a state transition, thetool then asking what is the arrival state of the transition and what isthe corresponding client request.

More generally, by clicking on a level of hierarchical list 720, it ispossible to add or remove an element of the immediately lower level.

Still in the context in which the tabs “FUNC” 612 and “Feature” 732 havebeen selected, if a state is pointed to and clicked on, there is thenobtained in the right part, in graphical zone 730, the groups ofelementary operations, represented as the nodes of an oriented graph,each arrow representing the data flow between the departure group ofelementary operations and the arrival group of elementary operations.This data flow is defined relative to the data flow between elementaryoperations, inasmuch as any datum that appears is in fact produced byone or more elementary operations of the departure group of elementaryoperations and consumed by one or more elementary operations of thearrival group of elementary operations.

Still in the context in which the tabs “FUNC” 612 and “Feature” 732 havebeen selected, if an elementary operation is pointed to and clicked on,there is seen in graphical zone 730 the set of other elementaryoperations and components (sensors, actuators) with which the elementaryoperation exchanges information. Once again, this is an oriented graph,and, on each link, there can be found the set of data exchanged betweenthe elementary operation that has been pointed to and the elementaryoperation or the component that is receiving or sending at the other endaccording to the direction of the arrow of the oriented graph. Theselected elementary operation is characterized by a specific color or bya specific location (center of the screen, red color), so that it can beeasily distinguished from other elementary operations and from sensorsand actuators. Similarly, the elementary operations other than thatclicked on in hierarchical list 720 are distinguished from components bytaking on a different color.

Still in the context in which the tabs “FUNC” 612 and “Feature” 732 havebeen selected, if the given level, or in other words the eighth level ofthe-hierarchy presented in the foregoing, is now pointed to and clickedon, there appears in the right part of the screen, in graphical zone730, a graph with the selected datum at the center of the graph and,surrounding this datum, the elementary operations that produce thisdatum (on the left) or that consume it (on the right) and possibly thesensor or sensors that produce this datum or the actuator or actuatorsthat consume it. Preferably the consumers are placed on the right andthe producers on the left. It is natural for there to be a plurality ofconsumers for one datum. It may be normal that the same datum isproduced by a plurality of elementary operations, for example if theyare not functioning in the same phases.

Depending on the level of the selected element of the hierarchical list,there is seen in graphical zone 730, when “feature” tab 732 is selected:

-   -   vehicle name: the oriented graph whose nodes are variants of        envelope service and the arrows are the data flows between these        service variants. Conditions are imposed on this graph by the        choice of a configuration, or in other words the choice of a        service variant per service. This is represented in FIG. 15.    -   services: the list of service variants and, for each, the        envelope view of the type of scheme 830.    -   service variants: envelope view of the type of scheme        illustrated in figure    -   phase: envelope view of the type of scheme illustrated in FIG. 8        for the elementary operations of the phase, restricting the        other services to mode combinations of the phase    -   state: envelope view of the type of scheme illustrated in FIG. 8        for the elementary operations of the state, restricting the        other services to mode combinations of the phase in which the        state is specified.    -   group of elementary operations: as when the “functional diagram”        tab is selected    -   elementary operation: a graph with, at the center, the selected        elementary operation and, around it, the sensors, actuators and        other elementary operations of the architecture in its entirety        to which it is linked, the edges of the graph being data flows        between the nodes.    -   datum: the elementary operations, sensors or actuators to which        the datum is directly linked are displayed in a graph. The        sensors or elementary operations that produce the datum appear        on the right, while the actuators or elementary operations that        consume the datum are placed on the left of the datum. The        arrows indicate the direction of movement of the datum (from the        producer to the consumer).    -   driver: the characteristics of the driver, of the input/output        type, analog/digital type, all-or-nothing type, its electrical        characteristics.    -   sensor/actuator: a graph with, at the center, the selected        sensor or actuator and, around it, the elementary operations of        the architecture in its entirety to which it is linked, the        edges of the graph being data flows between the nodes.

By selecting a service at the second hierarchical level, when“functional diagram” tab 731 is selected, there is seen in graphicalpart 730 the corresponding automaton, together with the states (oroperational situations) and the phase transitions only. In FIG. 7, thereis seen an automaton corresponding to the “badge” variant of the“openings” service: states 761 to 766 and transitions 768, 769 and 772.By clicking with the left button on an arrow representing a transition,a contextual menu appears that describes all the requests that lead tothis transition. Generally a single request causes this transition: forexample the “ignition_on” request, which corresponds to turning on theignition, for example with the ignition key, brings about a change fromthe “ignition not on” phase to the “ignition on” phase, although severalrequests originating from formalized use cases may link two states. Forexample, in a very simplified version of the unlocking service, it ispossible that the vehicle locked and vehicle unlocked states are linkedby the following client requests: “request for latching by badge” and“request for latching of the openings in the vehicle by control button”.Nevertheless, it will have been possible to formulate two differentformalized use cases, one for remote unlatching and the other forunlatching inside the vehicle.

The fourth level of hierarchy concerns the phases. When a phase isselected and when “functional diagram” tab 731 is selected, there isseen in graphical zone 730, under the name of the phase, the names ofthe states corresponding thereto, in rectangles.

By clicking on the transition between two states, it is possible toselect an elementary operation in order to specify implementationthereof, or in other words execution of the client request correspondingto this transition: this elementary operation will then have to take asargument the set of data-processing data originating from sensors,actuators or incidentally other services necessary for thedata-processing calculation that will be executed to decide whether ornot the client request is detected. In this way there are accessedsoftware translations of requests originating from phase transitions.

For each state, by means of a contextual menu that appears when thestate is clicked on with the right button, there are defined whichelementary operations must be activated (sensing, actuator instructions,control rules and their interfaces specified in other tools such asMatlab/Simulink, Statemate). They are grouped together according todifferent logics or practices of the designer.

By clicking with the right button on a phase in the fourth level of thehierarchy, there is made to appear a contextual menu that, among othercapabilities, makes it possible to link the phase to the modes (in acontextual menu there is seen a list of modes, such as energy, client,vehicle state, with check boxes for associating the phase with modecombinations). For example, the “crash” phase is specified in modes inwhich it is valid.

By selecting an element of the fifth level (“state”), still with“functional diagram” tab 731 selected, there is seen in graphical zone730 the part of the automaton concerning the selected state and thetransitions (or requests) that join the selected state and other states.In a state there can be added elementary operations: sequence ofoperations to be performed (acquisitions, instructions, control rules,algorithms). The state is right-clicked on and “add” is chosen: theselection is made in a list of elementary operations (technicallibrary).

It is then possible to create, if necessary, a new elementary operation,with which input and output data will have to be associated later on.

At the sixth level of hierarchy, the elementary operations are organizedin groups to facilitate navigation. The groups of operations contain thesame elementary operations for all horizontal tabs 611 to 616.

When an elementary operation is selected in the seventh level ofhierarchy, there is seen, in graphical zone 730, the data flow, or inother words the data exchanged by this operation (data in the input andoutput rectangles). If a group of elementary operations is selected inthe sixth, there is seen, in graphical zone 730, the data flow betweenthe elementary operations that it contains. If a state is selected inthe fifth level of hierarchy, there is seen, in graphical part 730, thedata flow between the groups of elementary operations that it contains.For each of the fifth to the seventh levels, if a link is selected inthe graphical part by clicking on the left button, there is seen, in acontextual menu, a list of exchanged data. By selecting one, it ispossible to modify it (see hereinafter).

When a datum is selected in the eighth level of hierarchy, there isseen, in graphical zone 730, all the elementary operations that consumeit and those that produce it, including those outside the state, serviceor phase.

The elements of the ninth and tenth levels of hierarchy (“driver” and“component”) are furthermore known and derive from the library of thevehicle maker, from equipment manufacturers or from suppliers.

To obtain a difference between the interfaces and controls of servicevariants on two different vehicles, for example, the service in questionis selected by right-clicking in list 720, and the “show differences”option is selected in a contextual menu. In a contextual dialog box,there is then selected the service variant of another vehicle that is tobe compared with the already selected service variant. There thenappears, in a contextual dialog box, a hierarchical list:Phase/State/Group of elementary operations/Elementaryoperations/Data/Drivers/Components of the two selected services,together with, at the different levels of the said hierarchical listthat is selected, a “+” sign when only the service variant selected infirst place contains the elements of the selected level, a “−” sign whenonly the service variant selected in second place contains the elementsof the selected level, a “!” sign if a difference exists at a levellower than the selected level, and no particular sign if the twohierarchical lists of the service variants being compared are identicalat this level.

Depending on the level of the selected element of the hierarchical list,there is seen in graphical zone 730, when “functional diagram” tab 731is selected: vehicle name: list of services services: list of servicevariants, service the graph whose nodes are the phases and the variants:oriented arrows are the client requests for phase change, phase: the setof states in a scheme such as that represented in FIG. 7, state: thedata flow of groups of elementary operations executed in the state,group of the data flow of elementary operations in the elementary groupof elementary operations, operations: elementary a graph with, at thecenter, the selected operation: elementary operation and, around it,those sensors, actuators and other elementary operations of thearchitecture in its entirety to which it is linked, the edges of thegraph being data flows between the nodes. datum: defined previouslydriver: defined previously component: defined previously

To go to the following step of the design of the architecture of theelectronic and data-processing system of hardware and softwarecomponents, the designer then selects “feature” tab 732. One of thescreens that corresponds to this selection is illustrated in FIG. 8. Inthis screen, whose text part 720 is identical to that illustrated inFIG. 7, if a service variant is selected (third level of hierarchy),there is observed in graphical zone 830 an envelope 840 of the servicevariant.

This envelope 840 is represented in the form of a rectangle, dividedhorizontally into two rectangular parts. The upper part is connected atthe left to representations of sensors 851 that supply it with data, andat the right to actuators 852 and 853, to which the service variantsupplies data. The lower part is connected at the left to entering data856 and 854 and at the right to exiting data 855. The data that merelypass through the variant without being used (or consumed) are notrepresented.

If an entering datum is clicked on with the left button, there isobserved, in a contextual menu, all sources of the selected datum, interms of elementary operations.

In this representation of envelope 840, there is used a formalism thatpermits a synthetic view of problems to be settled: an exclamation pointindicates a supposed conflict (for example, in the case in which, at theoutput, several services are trying to deliver the same datum), whichimplies settling an arbitration problem; a question mark opposite anentering datum for which no element has yet been defined to produce thesaid services.

This envelope representation 840 gives a synthetic view that is verypractical for the user of the design tool. If a datum, a sensor or anactuator is clicked on in the envelope representation, there is obtaineda functional view indicating the operational elements that produce thedatum and those that consume it. If one of these elementary operationsis selected or clicked on, then there is seen in a new screen the listof calculator variants onto which this elementary operation is mapped.This display is implemented in a new window, which appears at the timeof double clicking. By clicking on a sensor or an actuator, there isobtained the list of service variants that exploit this component aswell as the list of calculator variants to which the component isallocated. Return to normal is effected by closing the windows createdin this way.

In addition, the services with which the selected service exchanges dataappear directly in boxes such as 855 directly associated with the inputand output data of the service. When several services consume or producea datum, then this is not the name of one of the services displayed butis the sequence “ . . . ”, in which case it is necessary to click on thebox similar to 855 to see the list of services displayed in a newwindow.

When a datum is produced or consumed by an elementary operation that isnot allocated to a service, then a specific icon 854 is seen to appear,associated with the datum. Under certain circumstances, for example whenthe description of elementary operations has been recovered from acalculator but these elementary operations are not linked to a service,this type of notation makes it possible to know that the elementaryoperation producing datum G in our example has indeed been defined andmapped.

To go to the following step of design of the architecture of theelectronic and data-processing system of hardware and softwarecomponents, the designer then selects “MAP” or “feature architecture”tab 613. One of the screens corresponding to this selection isillustrated in FIG. 9.

As is evident in FIG. 9, user interface 900 of this software tool thencomprises:

drop-down menus 601 to 608,

six horizontal tabs 611 to 616,

a hierarchical list zone 920,

a graphical zone 930, and

vertical tabs 931 and 932.

Vertical tabs 931 and 932 are respectively named “networks” and“feature” and are attached to graphical zone 930. They are used toselect a content to be displayed in this graphical zone 930, asexplained hereinafter.

At the left, there is seen hierarchical list 920, which contains part ofthe list in which the seven highest levels of hierarchy are as follows:

-   vehicle name    -   services        -   service variants            -   group of elementary operations                -   elementary operation                -    data                -     driver                -      sensor/actuator

The highest three levels of hierarchy are identical to those ofhierarchical lists 620 and 720 and in particular contain the services.Selection of one of the components of the hierarchical list by leftclicking causes, together with the “network” tab 931, selected, the setof networks 941 to 943 of calculators 951 to 955 to appear in graphicalpart 930, as a synthetic representation in which, for the selectedelement, the distribution thereof over the calculators and data flowsconcerning it on the networks can be observed.

Depending on the level of the selected element of the hierarchical list,the set of networks (the nodes and the different networks) is observedin graphical zone 930, when “network” tab 931 is active.

Each network is represented together with all calculators connectedthereto, the network possessing a specific color, represented here bystickers, labels or patches 961 to 963 marked with “+”, “×” or “∘”signs. Calculators present on two networks—calculators 951 and 955—areendowed with “sticker(s)” on each network to which they are connected,each “sticker” having the color, represented here by the sign,corresponding to each other network to which the calculator in questionis directly connected. The stickers therefore give a three-dimensionalview without complexity of representation.

By clicking with the right button on a network, there is observed, in adialog box, the list of data being transported on the said network. Theicons representing the data, which are followed by their name in cleartext, appear in green on a white background if the datum in question isnot placed in a frame circulating on this network, in blue on a whitebackground if the data is placed in a, frame and in blue on a graybackground if the datum is not being used by any calculator, whetherthis calculator is directly on the network or is accessible via bridgecalculators between the network and other networks.

These views permit an estimate of the bus load in the mean time betweentwo transmissions of the same datum. This mean time is estimated, forexample, by taking into account the communication protocol used on thenetwork under consideration and displayed in the contextual andperformance window of the said protocol, for example

the load level that saturates the network (on the basis of 30% load fora CAN, it is found that the most critical frames cannot arrive in thedesired time because of the arbitration mechanism, which delays thetransmission of a frame if the sending of another frame of higher orequal priority has already been requested), and

the share of the data flow that results from protocol management (50%for a CAN, typically because the protocol management data (arbitration,CRC, etc.) represent practically as many bits on average as the dataeffectively transported by a frame).

The data flow is calculated per mode, and the highest load is taken inthe mode in which it appears. This aspect is motivated by the fact that,for example, in diagnostic mode, certain frames corresponding to aclient mode are inhibited and therefore need not be taken into accountin the load calculation. Reciprocally, the load calculation duringoperation for the final client does not have to take diagnostic framesinto account. A frame is emitted in a given mode if and only if at leastone of its data is exchanged between two elementary operations that areactive in this said mode.

With “network” tab 931 selected, the tool user can effect mapping of aservice variant or of a group of elementary operations, or else mappingof an elementary operation selected in the zone of list 920, onto one ormore calculators represented in graphical part 930, by the well known“drag and drop” function (which can be translated into French by “shiftand release”). To this end, when a service variant or a service isclicked on with the right button, a contextual menu appears and proposesthe different types of mapping.

If an elementary operation exists in several service variants, forexample the elementary operation “Unlatch trunk”, which in hierarchicallist 920 in FIG. 9 is linked to both the “badge variant” and the “keyvariant”, then the fact of mapping this elementary operation, forexample onto calculator 953 of the BRF type, at the moment of mapping ofthe “badge variant” service, will also map this elementary operation forthe “key variant” service and, even if the “key variant” service issubsequently mapped onto the calculator of UCH type, only the elementaryoperations not yet mapped will be mapped onto the calculator of UCH[passenger-compartment control unit] type, the “Unlatch trunk”elementary operation remaining mapped onto the calculator of BFR type.The situation would be the same with a group of elementary operations ofa service variant other than the “badge variant”, if it were to containthe “Unlatch door” elementary operation and be mapped, for example ontothe calculator of UCH type. In this way, the elementary operationsshared among several services are mapped only one time. In addition,once an elementary operation is mapped, its mapping can be canceled andreplaced by another type of calculator by clicking in a menu obtained byselecting the said elementary operation by right clicking.

The different types of mapping include, in particular, mapping onto asingle calculator, master-slave mapping and distributed mapping. In themaster-slave type of mapping, the “control” part of the service sendsinstruction messages on at least one network to instruct each slave, andthe tool automatically adds these instruction messages in or outsidealready defined frames (see hereinafter). To be able to map the masterand slave when the master-slave type of mapping is selected, anelementary operation, representing the control automaton of the service,is automatically added in relationship with the service variant underconsideration. It is called “elementary control operation”. Thereafter,by drag and drop operations, the service variant or a group ofelementary operations or one elementary operation and in particular theelementary control operation are mapped onto a calculator variant. Thereare as many slaves as there are nodes onto which the elementary controloperation is not mapped and onto which at least one elementary operationof the service is mapped. The node onto which the elementary controloperation of the service is mapped becomes the master node.

The first step before mapping as master and slave is to synthesize thecontrol operation. For this purpose, it is considered that thisoperation consumes all the data that permit calculation of the controlautomaton of the service. For example, if a transition is conditionalupon a Boolean datum “a” being set to unity, where “a” is the result ofan elementary operation, then the elementary control operation in thecase of a master-slave mapping will in particular have “a” as inputdatum.

The distributed type of mapping means that elementary operations of thesame service are distributed onto a plurality of calculators and that,in addition, the control automaton of the service is synthesized on eachof the said calculators.

Thus, on each node onto which at least one elementary operation of theservice has been mapped, there is automatically added, at the instant ofmapping, an elementary control operation that represents the controlautomaton of the service. This elementary control operation is the sameas that which would have been synthesized automatically for mapping ofthe master-slave type.

For each mapping of a service, a mapping dialog box appears to ask ifthe elementary operations, the sensors and actuators in question must bemapped simultaneously and onto the same calculator. If the decision ismade to map the service together with the actuators and/or sensors inquestion, the design tool connects then to the calculator. If theelementary operations, the sensors and/or the actuators are not mappedonto the same calculator as the rest of the service, the design tooladds the data necessary for good operation of the service inside oroutside already defined frames (see hereinafter).

If, at the instant of mapping onto a node, or in other words onto a typeof calculator, several calculator variants implement this type ofcalculator, then a dialog box appears to ask onto which of these saidcalculator variants the selected component must be mapped.

As illustrated in FIG. 10, if “feature” tab 932 is selected and aservice variant is selected (second level of hierarchy), there is seen,in graphical zone. 1030, positioned one below the other, all envelopes1061 and 1062 of calculator types containing at least one elementaryoperation of the selected service. Only those input and/or output dataof elementary operations of the selected service variant that arecontained in these types of calculators are displayed, thus making itpossible to see, for the said service, the state of progress of mappingand the state of internal and external exchanges of the service variantwithin the electrical and electronic architecture. If data such as V2 orV3 are produced or consumed by other service variants, then this isindicated with the same conventions as in zone 841 in FIG. 8.

Also evident in graphical zone 1030 are the same-two types ofcalculators 1041 and 1042, corresponding respectively to 1062 and 1061,on which is installed the selected service variant, as well as the dataflows that they exchange. By clicking on one of the arrows 1043 and 1044representing these data flows, there are seen the exchanged data in adialog box (not illustrated). In these boxes there would be seen thedata V2 and V3, which are the only exchanges, internal to the service,between the calculators of the UCH and BFR type.

If data frames were being exchanged, they would be represented inenvelopes 1061 and 1062 in the manner of the representation in zone 1244of FIG. 12.

These graphical representations are updated following evolutions of themapping of elementary operations of this service variant.

If “feature” tab 932 is selected and an element of one of the fourth tosixth levels of hierarchy is selected, the data flows are seen ingraphical zone 1030 (see “Func” tab 612 hereinabove), albeit for allstates together (hierarchical list 820 no longer contains a levelrepresenting the states).

The first three tabs, 614 to 616, concern the hardware withdiversity-type management, or in other words different variants ofhardware implementation of the system.

When the designer selects “operational architecture” or “OPER” tab 614,he accesses a description of the elementary operations of eachcalculator. FIG. 11 shows a user interface that is displayed when “OPER”tab 614 is selected.

As is evident in FIG. 11, user interface 1100 of the software tool thencomprises:

drop-down menus 601 to 608,

six horizontal tabs 611 to 616,

a hierarchical list zone 1120, and

a graphical zone 1130.

At the left, there is seen hierarchical list 1120, which contains partof the list in which the six highest levels of hierarchy are as follows:

-   vehicle name    -   calculator type        -   calculator variant            -   service                -   elementary operation                -    data                -     driver                -     sensor or actuator

Depending on the level of the element selected in the hierarchical list,there are seen in graphical zone 1130:

calculator type The data flow between the different nodes of thenetwork, regardless of whether this flow is implemented in frames ornetworks of all kinds. If an elementary operation mapped onto a nodeconsumes a datum produced by another elementary operation on anothernode, then the exchanged datum appears in the data flow representedgraphically by an arrow directed from the node in which the data areproduced toward the node in which the data are consumed.

calculator variant The oriented graph, in which the nodes are theelementary operations mapped onto the calculator variants, 1140, 1142,1144, 1146, 1148 and the arrows, such as 1162, are data flows betweenthese elementary operations.

elementary operation The links to the sensors and actuators linked tothe selected elementary operation and installed on the calculator.

data The elementary operations, sensors or actuators to which the datumis directly linked are displayed in a graph. The sensors or elementaryoperations that produce the datum appear to the right, while theactuators or elementary operations that consume the datum are positionedto the left of the datum. The arrows indicate the direction of movementof the datum (from the producer to the consumer).

-   -   Driver the characteristics of the driver, input/output type,        analog-digital type, all-or-nothing type, its electrical        characteristics.    -   Sensor/actuator a graph with, at the center, the selected sensor        or actuator and, around it, those elementary operations of the        architecture in its entirety to which it is linked, the edges of        the graph being data flows between the nodes.

FIG. 12 shows a user interface that is displayed when “hwd” or “hardwarearchitecture” tab 615 is selected.

As is evident in FIG. 12, user interface 1200 of the software tool thencomprises:

drop-down menus 601 to 608,

six horizontal tabs 611 to 616,

a hierarchical list zone 1220,

a graphical zone 1230, and

vertical tabs 1232 and 1234.

At the left, there is seen hierarchical list 1220, which contains partof the list in which the six highest levels of hierarchy are as follows:

-   vehicle name    -   calculator type        -   calculator variant            -   frames                -   datum in the frame            -   sensor/actuator                -   data                -    driver

Depending on the level of the element selected in the hierarchical list,there are seen in graphical zone 1230, when “networks” tab 1232 isselected:

vehicle name the networks of this vehicle architecture

calculator type the networks to which this type of calculator isconnected, represented in FIG. 16

calculator variant the networks to which this calculator variant isconnected

frames or the network to which this frame belongs datum in the networkframe to which this datum belongs (via the frame)

sensor/actuator the type of calculator to which this component isconnected and the networks on which this type of calculator isconnected.

Data None

Driver None

and, when “Diagrams” tab 1234 is selected:

vehicle name None

calculator type A graph whose nodes are the calculator types and whosearrows are the frame flows, the arrows being oriented from the sendernode to the receiver node.

calculator variant display as defined in FIG. 12 by the contour 1260divided into three parts 1240, 1242 and 1244 by two horizontal lines1262 and 1264. In zone 1240, the links of the calculator variant tosensors or actuators are displayed, the links to the sensors 1252 beingdisplayed on one side and the links to the actuators 1250, 1254 beingdisplayed on the other side. In the diagram, in the case of acquisitionof information originating from a sensor 1252, the datum appears insidecontour 1260, while the name of the sensor, “Key”, appears outside thecontour. In this way, the designer can easily distinguish the names ofthe data of the application software installed on the calculatorvariant, the names of the different sensors and actuators and, inaddition, the link of the sensors/actuators to the software data isclear. In zone 1244 there are represented the electronic messagingsystem interface of the selected calculator variant. This electronicmessaging system interface is composed of message frames consumed orproduced on the various networks to which the selected calculatorvariant is connected. The consumed frames are represented by one side ofthe zone and the output frames are represented by the other side. Forexample, T_in_(—)1, is an input frame 1246, and T_out_(—)1 andT_out_(—)2 are sent frames 1247 and 1248 respectively. Only the dataeffectively consumed and produced by at least one elementary operationon the selected calculator variant are represented in zone 1244 incorrespondence with the different frames. For example, if a site for adatum “n” is reserved in. T_in_(—)1, and if the datum “n” is notconsumed by any elementary operation on the selected calculator variant,then “n” does not appear in zone 1244. Reciprocally, the datum “a” thatappears in correspondence with T_in_(—)1 is therefore consumed by anelementary operation mapped onto the selected calculator variant.Finally, in zone 1242, there are found those input and output data ofthe selected calculator that are linked neither to sensors/actuators norto frames and that nevertheless originate from or are destined for othernodes. The conventions of zone 841 are used for this zone 1242. Finally,the data that merely pass through the selected calculator variant, whichthen acts as a bridge between networks, are accessible in the form of alist by selecting menu tab 603. The separation of the data into twocategories, not yet assigned and already assigned, provides a coherentview of what has been done and what remains to be done.

Frames none

datum in the frame elementary operations and/or sensors/actuators thatare producers or consumers inside the selected calculator variant.

sensor/actuator a rectangular contour (not illustrated) separated intotwo parts, the upper part being used to indicate the data produced bythe sensor/actuator by means of a driver and used on calculators otherthat the calculator to which the component is allocated, the lower partsbeing used to represent the data produced by means of a driver and usedon the calculator to which the component is allocated. The data receivedby the component are on the left of the contour, while the sent data areon the right of the contour. Such a datum-calculator link is representedin a manner similar to data-service link 855 in FIG. 8, apart from thefact that, if the same datum is, for example, sent to a plurality ofcalculators, then it will be repeated a plurality of times, which is analternative to a display of the type “ . . . ”, with a box on which itwould be necessary to click in order to access different calculatorvariants that are other than that to which the component is allocatedand that are using the datum.

data of a sensor or actuator elementary operations and/orsensors/actuators that are producers or consumers inside the selectedcalculator variant.

Driver as for the datum, see above.

When “networks” tab 1232 is selected, the hardware architecture and themapping of calculators onto networks is seen-in graphical part 1230.

Each network is represented together with all calculators connectedthereto, the network possessing a specific color, represented here bystickers marked with “+”, “×” and “∘” signs as in FIG. 9. Calculatorspresent on two networks are endowed with “sticker(s)” on each network towhich, they are connected, each “sticker” having the color, representedhere by “+”, “×” or “∘” signs, of other networks to which the calculatorin question is directly connected. The stickers therefore give athree-dimensional view without complexity of representation.

By clicking with the right button on a network, there appears, in acontextual dialog box, the list of data circulating on the said network.In this dialog box, different colors indicate the data that are notallocated in a frame, those that are allocated and are being effectivelytransported in a frame, and those that are allocated but are not beingeffectively transported because, for example, they are not produced.

The data circulating on a network are visible in a dialog box byclicking with the right button on the network in question, “networks”tab 1232 or 1232 being active. This dialog box uses colors to indicatemapping of the data in a frame and the use of the data, as explainedhereinabove with regard to FIG. 9.

When tab 616 is selected (screen not illustrated), if a datum isselected by clicking on the, left button, a pop-up menu makes itpossible to reach a contextual dialog box that provides information onthe said datum, especially the dimension (a Boolean value with a size ofone bit), the extreme values, a default value and the maximum age of thedatum, or in other words the time after sensing, at the end of which thedatum can be regarded as obsolete, etc.

When “msg” tab 616 is selected, there is obtained, in the right part, ascreen analogous to that of FIG. 16 when tab 1232 of FIG. 16 isselected. There is then seen, in the right part of the screen, for eachvehicle, all the frames being transported by at least one network and,in the left part of the screen, a representation of different networks,as in zone 1630 in FIG. 16. By clicking on a frame, only the network onwhich the frame is circulating is displayed. By clicking on one of tabs1652, 1654, 1656, 1658, only the frames circulating on the correspondingnetwork are displayed in the left part of the screen. When tab 1231 isselected and a frame is clicked on, a presentation of the frame appearsin the right part of the screen, showing the essential information ofthe frame, in particular its size, its period, the type of network thenthe list of data for which space is allocated as well as the coordinatesof this space in the form of byte number and most significant bit andsize, then the list of calculator variants that are producers andconsumers for each datum.

In the graphical zone corresponding to the selection of tab 616, byclicking with the left button on a calculator, there is seen, by meansof a pop-up menu giving a choice between (left, right), (top, bottom),(front, rear) are to be used and which directions they are to have. InFIG. 13, for the case of a motor vehicle whose zones are represented ina view from above, the orientation permits the person skilled in the artto recognize certain of these zones, such as roof 216, then, step bystep, all of the zones represented. In order to make this division intozones more legible, it is possible to name the zones. As an example,this is the case of the right front fender named fender AVD 1346.

FIG. 14 represents a local view of one of the vehicle zones representedin FIG. 13 in subscreen 1330 of screen 1300. This is accessed, forexample, by selecting the said zone in subscreen 1330 then doubleclicking.

In subscreen 1330, it is possible to stipulate the dimensions of thesaid zone by selecting button 1410 then selecting one of the vertices ofthe said zone and moving it as desired, while the other vertices remainunchanged. Selecting a contour point of the zone other than a vertexmakes it possible to define a new vertex.

A prohibited subzone can be specified by selecting a button 1412 thenplacing the zone where it is wished to map the prohibited subzone. Theprohibited subzone is then mapped in the form of a rectangle having thedefault dimensions. The exact dimensioning of the subzone is thenapplied, as for the vehicle zone, by selecting a button 1410 thenselecting one of the vertices of the selected prohibited subzone, or byadding a vertex by selecting a contour point other than a vertex.

The routing points are mapped onto the zone by first selecting a button1414 then selecting the location of the zone in which it is wished tomap the said routing point. The connecting points of the zone are mappedby first selecting button 1416 then selecting the location of the zonein which it is wished to map the said connecting point.

As in FIG. 14, a compass can be positioned beside the zone by selectingbutton 1316, then oriented.

A recommended routing pathway can be mapped by selecting a button 1418then selecting an initial component or routing point or connectingpoint, then a final component or routing point or connecting point.

The components and calculators are mapped onto the zone by clicking anddragging from hierarchical list 1420. They can be associated with icons,by means of which they can be located and recognized more quickly.

All elements of the vehicle zone represented can be moved and adjustedby clicking and dragging. Finally, a “ruler” element can be placed inthe window to facilitate dimensioning of the different zones. For thatpurpose, a button 1413 is selected then the location of the zone inwhich it is desired to position the ruler is selected. By selecting oneof the ends of ruler 1444, it is possible to lengthen or shorten it.While this operation is being performed, the real length of the ruler isdisplayed, for example in millimeters.

It is possible to rotate the ruler around one of its vertices by knownmeans. Positioning the ruler along one of the sides of the zone makes itpossible to know the length thereof and if necessary to change itsdimensioning.

Still with the objective of the most faithful representation possible,it is possible to make a background grid appear in subscreen 1430, sothat the zone can be represented true to scale. As an example, thebackground grid can be composed of parallel and regular horizontal andvertical lines, dividing the space into squares of 20 mm by 20 mm on ascale of 1:1.

For convenience of use, it is possible by known means referred to aszooms to enlarge and shrink the vehicle zone represented, or in otherwords to change the scale of the figure to adapt it to the part ofsubscreen 1430. The zone and all elements positioned on the screen thenchange in scale.

Once the operation of mapping of connecting points onto different zoneshas been effected, it-is possible to return to the view presented inFIG. 13 in order to link the connecting points of the different vehiclezones corresponding to one another in subscreen 1330. In a certaindisplay mode, which is accessible via “View” menu 603, there appear the,connecting points specified in zone 202, for example. This zone containsthree connecting points 1350, 1351, 1355. As for zone 220, it containsone connecting point 1353 for the time being. To indicate, for example,that connecting points 1355 and 1353 correspond to one another, or inother words that they in fact represent the same point in space, it ispossible, for example, to select button 1314 then to select connectingpoint 1355 then to select connecting point 1353. A graphical link 1354is then automatically generated. If desired, “View” menu 603 can bereselected to hide all connecting points and their links.

It is possible to name the connecting points, as is done, for example,for connecting point 1448, “C3”. In this case, the name of theconnecting point is repeated in subscreen 1330, if the option to displaynames of connecting points is activated.

The routing algorithm is executed by selecting the “Synthesize cabling”option in “Edit” menu 602. It is then possible to view the result. InFIG. 14, segments 1451 to 1455 have been synthesized. By clicking oneach of these segments, there is obtained the list ofcomponent-component or component-connector or connector-component linksor wires that are inscribed in each of these segments.

For example, if engine 406 possesses a three-pin connector, one of lowpower for control, one of high power for supply and the third forground, the following list is obtained:

Engine-1—control datum of engine 406

Engine-2—supply of engine 406

Engine-3—ground of engine 406

If these three pins are associated respectively with three pins ofconnector 1447, C1, the following list is seen:

C1-3—control datum of engine 406

C1-5—supply of engine 406

C1-1—ground of engine 406

Then, by clicking on link 1452, it is seen in the display that, on thesegment between routing points 1470 and 1472, there circulate thefollowing reference links:

Engine-1—control datum of engine 406; C1-3—control datum of engine 406

Engine-2—supply of engine 406; C1-5—supply of engine 406

Engine-3—ground of engine 406; C1-1—ground of engine 406

FIG. 15 represents the screen that appears when “Vehicle Z23” isselected and “Func” tab 612 is selected. There is then obtained ingraphical part 1530, at the right of the screen, a graph whose nodes areservice variants and whose arrows are data flows exchanged between theservice variants. Such a data flow represented by an arrow between adeparture service variant and an arrival service variant is defined bythe set of data that are produced by at least one elementary operationof the departure service variant, that are not produced by anyelementary operation of the arrival service variant but that areconsumed by at least one elementary operation of the arrival servicevariant.

The inter-service data flow such as represented in FIG. 15 is generatedfor a choice of a service variant for each service corresponding to aconfiguration. For the person skilled in the art, these data flows makeit possible to flag the data for which precautions are to be takenduring development. In fact, the data between services and theircharacteristics must be validated for each service that consumes orproduces them, in contrast to the data intrinsic to a service, theperfecting of which data is derived solely from the said service.

In the screen illustrated in FIG. 15, it is possible to represent theintegrality of the exchanges between all services of the product or theexchanges of a subset of services, by copying the said subset ofservices into a product architecture for example created for theoccasion, and by considering the corresponding graph in graphical part1530.

FIG. 16 represents a screen that appears by selecting “HWD” tab 615,“Network” tab 1232 and UCH node 1621 in hierarchical list 1220. Therethen appears, in graphical part 1630, a network view that follows thesame conventions as the view described in graphical part 830 illustratedin FIG. 8. Only the networks on which UCH node 1621 is present are thendisplayed, in contrast to what is represented in FIG. 8, where allnetworks are displayed. Tabs in a zone 1640 make it possible to selectthe different networks of architecture 1654, 1656, 1658. Selecting “all”tab 1652 makes it possible to display all networks in graphical part1630 and cancels the selection of UCH node 1621.

By clicking on a given network, there is obtained the set of datacirculating on that network, while distinguishing in particular thosethat are not stocked in frames, those that are stocked and are present,those that are stocked and are absent.

The method for designing a specification of a service variant isdetailed in FIG. 17.

Steps 1712 and 1714 are syntheses effected automatically for the tool,while the other steps are assisted by virtue of the ergonomics of thetool but are left to the initiative of the designer.

During design of the specification of a service variant, the use casesare first specified (step 1702). Once the use cases have been specified,there are identified the operating phases, the client requests which arethe transitions, and the system responses which are the states (step1704). The phases are defined preferentially by their decomposition intotransverse modes, as is presented in FIG. 7. Preferentially, two phasesshould not share a combination of transverse modes. It is then possibleto synthesize a first automaton describing the supervision of theservice, such as detailed in FIG. 7. The starting point for that purposeis the association of use cases with triplets (departure state, clientrequest, arrival state) as proposed by the user.

From these first three steps, supported by the REQ tab of the tool, acontrol automaton of the service is automatically synthesized for alluse cases of the service (step 1712).

This is followed by the steps of correction (step 1714), and completion(step 1716), which make it possible to perfect the automaton and enrichthe use cases (step 1720) as a function of new situations, identified inparticular during the completion step (step 1716).

In parallel with the steps of developing the control automaton of theservice (steps 1712, 1714 and 1716), there are specified the elementaryoperations executed in each of the states of the control automaton ofthe service (step 1706).

Similarly, certain elementary operations executing phase transitions areidentified (step 1708), as well as elementary operations executingclient requests (step 1710). The execution of a phase or statetransition by an elementary operation is represented preferentially byan elementary operation whose result is a Boolean which, when it has theBoolean value of “true”, results in activation of the said transition.In equivalent manner, but for more generality, it is possible to specifythat the transition operates for a particular value of one of theoutputs of the elementary operation that executes it.

When steps 1706, 1708 and 1710 are partly or completely executed, thedata flow between the elementary operations specified in the course ofthese steps is synthesized (step 1718).

It is then possible to synthesize a model of the specified servicevariant (step 1722), by supplementing, with the description of sensorsand actuators preferentially attached to the service and ofcorresponding drivers, particularly the automaton synthesized in thecourse of step 1712 and the different elementary operations attachedthereto.

FIG. 18 describes a method for designing an electrical and electronicarchitecture that makes it possible to understand not only theinteractions between the different steps of the method described in theinvention but also the different views proposed by the tool.

As the starting point, a specification of the configurations of theproduct is specified by the user (step 1802). It indicates the differentconfigurations, characterized in particular by a set of service variantsand a set of calculator variants. For each configuration, there isindicated a percentage corresponding to the ratio of the number ofproducts containing the said configuration divided by the total numberof products. Once this step has been executed, a specification of eachservice variant is produced (step 1806), in particular by applying themethod described in FIG. 17. It is then possible to proceedautomatically to validations of the service architecture (step1808—described later). For a set of configurations specified in thecourse of step 1802, there is specified a set of nodes and of networksconnecting them and, for each node, a set of calculator variants (step1810). In addition, the product geometry is specified (step 1804). Oncesteps 1806 and 1810 have been partly or completely executed, it ispossible to map the services onto the different nodes (step 1812). Thereis then automatically executed a synthesis of the control of theservices (step 1816) as well as the synthesis of the exchanges, inparticular on the different data buses (step 1818). On the basis ofexchanges on the buses (step 1818), it is possible to specify anelectronic messaging system or to generate it automatically (step 1826),for example by means of the method described in French PatentApplication No. 01-05713 of 27 Apr. 2001, which is incorporated here byreference.

In addition, the different calculator variants specified in the courseof step 1810, and the different sensors and actuators, in particularthose attached to the service variants specified in the course of step1806, are mapped onto the geometric description of the vehicle (step1814). The routing points, connecting points, connectors and prohibitedzones are mapped similarly (step 1820).

On the basis of mapping of the different electrical and electroniccomponents (step 1814) and of the description of the geometricconstraints (step 1820), there is synthesized the routing of thesignals, in particular those for data, power or links to ground (step1822).

In addition, the characteristics of the different elementary operationsare specified in terms of code volume, necessary random-access memoryspace and CPU consumption (step 1824). Given the routing (step 1822) onthe one hand and the specification of the resources necessary forexecution of the software components that execute the elementaryoperations (step 1824) on the other hand, there is deduced an estimateof the cost of the system on the basis of the cost of the electricalarchitecture (sensors, actuators, wires, connectors) and the costrelated to the types of inputs-outputs and to the choice of processorsimposed by mapping (step 1830). This synthesis (step 1830) is executedby taking into account in particular the optimization imposed by spliceson the power and ground wires (step 1828). Finally, once all these stepshave been executed, the evaluated architecture can be compared withother architectures, in particular by a cost, quality or weightcriterion, and especially by a cost criterion that in particularconsolidates the quality and weight criteria (step 1832).

In order to achieve a consolidated quality estimate, several steps mustbe executed:

-   -   automatically calculating a measure of quality for execution of        one elementary operation and for execution of a set of        elementary operations on a calculator, given a measure of        quality for each type of input-output, for each type of wire        (power, ground, data) and given a measure of quality for        execution of an instruction on a calculator, for an access to        random-access memory and for an access to flash memory,    -   automatically calculating the quality of the routing    -   taking into account a measure of the quality of the sensors and        actuators    -   automatically deducing the quality of the electrical and        electronic architecture

The operations of validation and support therefor by traceability meansare not described in FIG. 18, nor is control of operating safety, butthey supplement this figure recapitulating the global method.

As regards the configurations, it is possible to distinguish:

the basic services, which may be required by law or are commonplace invehicles (lighting, windshield wipers, etc.),

the basic services with variants, such as motor function in a vehicle,which may be based on a gasoline or diesel internal combustion engine,on an electric motor or on a hybrid motor, for example, with a differentimplementation in each case,

the services that will not necessarily be integrated into all productsand that can be characterized as optional. An example is airconditioning in an automobile.

The service is configured by selection of a set of service variants(optional or otherwise). The optional services of the configuration arethose that are not always present.

For a given configuration, the installation proportion of optionalservices will be given in particular as a percentage.

For a given product, different configurations will be envisioned.

Considering all of the configurations, the respective percentage of eachconfiguration will be given, for example in the form of a percentage.

Taking an automobile as an example, a distinction is made between theluxury, comfort and “eco” (for “economic”) configurations with, forexample, an air-conditioning service in 100% of the luxuryconfiguration, 40% of the comfort configuration and 0% of the ecoconfiguration. The luxury, comfort and eco configurations willpotentially represent respectively 20%, 50% and 30%.

The configurations planned for a product have an impact on the choice ofhardware architecture of the product. For example, air conditioning witha low installation proportion (10%) will be reason to implement this airconditioning by means of a specific calculator, whereas, if the airconditioning is present 100% of the time, there will be a tendency tointegrate the software and the corresponding hardware interfaces in acalculator that combines numerous other services. It is in fact costlyto multiply the number of electronic calculators, and in practice it isdesirable to integrate as many services as possible in order to lowerthe costs.

The configurations are also used to make the choices of cabling, theforegoing example of air conditioning readily demonstrating this, sincethe cabling for a specific calculator will have a cost different fromthat of the cabling for a non-optional calculator. The choice of anoptimal electrical-electronic architecture is therefore madepreferentially as a function of a pre-defined set of configurations.

The configurations are also used to manage the diversity, by making itpossible to limit the available combinations of options for each design.

They also represent an intermediate element that makes it possible tosimplify the validations, as will be seen hereinafter.

Via the step of mapping of services onto calculators, it is possible todeduce the calculator configurations associated with a serviceconfiguration. These are in particular calculators that contain at leastone elementary operation of at least one service of the serviceconfiguration. The optional character of the calculator is also deduced;a calculator containing in particular elementary operations attachedsolely to optional services will potentially be optional.

Nevertheless, configurations of calculators and hardware components canbe defined, in particular if the mapping step is not yet executed.

When a configuration is specified as being composed of a serviceconfiguration and a calculator configuration, it is assumed that everyservice of the service configuration is indeed entirely mapped onto thecalculator configuration and that, reciprocally, the elementaryoperations originating from services that are not in the serviceconfiguration are deactivated on the said calculator configuration.

A constraint associated with the configurations is integrated into thechoice of an optimal routing. A component in which at least one variantis absent from at least one configuration is said to be optional. Theeconomically optimal routing is, for example, that which satisfies thefollowing constraints:

1) it is not possible to link a component (sensor, actuator) to anoptional node in such a way that there exists at least one configurationin which the node is absent and the component is present. Thus, in thesearch for the routing of the said component, the nodes that do notsatisfy the foregoing criterion are not considered.

2) it is not possible to connect into a power splice two wires thatwould not be present in the same configurations.

3) under the foregoing assumption 1), when the routing of a wireoriginating from an optional component C is synthesized and when theoptimal routing ends at a node N_(n) such that there exists at least oneconfiguration in which node N_(n) is present and component C is absent,then an attempt is made to synthesize at least one other routing byconsidering all the nodes other than N_(n) that satisfy condition 1).The routing then links the component to a new node N_(n+1). Thisoperation is iterated until there is found a node N_(p) such that N_(p)is the last node traversed that satisfies 1). For the set of routingssynthesized in this way (the last being routing N_(p)), there is appliedthe cost calculation weighted by the installation proportion of thedifferent components, meaning that a component that is present in 40% ofthe configurations will have a cost weighted by 0.4. The routing thatminimizes the cost is the economically optimal routing for the set ofconfigurations.

For example, it is possible to allocate the air-conditioning compressorto the air-conditioning node (optional, and installed specifically forthe air-conditioning service) or to the passenger-compartment calculatornode (always present). The connection to the air-conditioning node coststwo euros, for example by integrating the cost of one euro for theconnector of the calculator for the connection to the compressor and tothe other components, and the cost of one euro for the wires, comparedwith one euro for the passenger compartment controller. If theinstallation proportion of air conditioning exceeds 50%, then it isnecessary to route the compressor to the passenger-compartmentcontroller node, otherwise to the air-conditioning node. For example,with an installation proportion of 40% and for one hundred units, therouting to the passenger-compartment node costs 1*100*1 euros, equalingone hundred euros, whereas the routing to the air-conditioning nodecosts 0.40*100*2 euros, equaling eighty euros.

Knowledge of the relative costs of the drivers as a function of thenumber of units makes it possible to refine the economic estimate. If adriver of PWM type (pulse width modulation) costs 1 euro for a series of40,000 units but only 0.5 euro for a series of 100,000 units, then for aseries of 100,000 units and an air-conditioning installation proportionof 40%, the cost of the driver on the air-conditioning calculator willbe 1 euro, whereas the cost of the driver on the UCH calculator will be0.5 euro, and the economic equation becomes 100+100*0.5 euros, equaling150 euros for the UCH and 80+0.4*100*1 euros, or 120 euros for thescenario of routing on an air-conditioning calculator. It is thereforealways of interest to choose the “air-conditioning calculator” scenario.

If there is now estimated an installation cost, calculated as a functionof

-   -   a cost of installing a strand necessary for implementation of        the air conditioning on the cockpit zone, for example,    -   a cost of installing a connector necessary for implementation of        the air conditioning on a boundary of the cockpit zone or on the        cockpit zone,    -   a cost of installing the air-conditioning and/or        passenger-compartment calculator on the cockpit zone or another        zone specified by the designer,    -   a cost of installing sensors or actuators necessary for        implementation of the air conditioning on a zone and    -   a cost of connecting the different actuator connections        necessary for implementation of the air conditioning between        zones or in a zone,        then, given an evaluation of 1 euro for the optional        air-conditioning calculator and of 2 euros for the        passenger-compartment calculator and assuming an installation        proportion of 40% for the air-conditioning service, the option        of routing on the air-conditioning calculator comes to 120        euros+0.4*100*1+1*100*2 euros, or 360 euros whereas the cost of        routing on the passenger-compartment calculator is 150        euros+1*100*2 euros, or 350 euros.

Suddenly the air-conditioning calculator is no longer justified. Let usfurther refine our analysis.

For both the air-conditioning calculator and the passenger-compartmentcalculator, let us assume a quality impact of 100 ppm (failures permillion) over 3 years, a typical warranty period. In addition, let usestimate the mean cost of replacing the calculator as 200 euros and letus assign an installation/removal cost of 50 euros for the zone in whichthe air-conditioning calculator is located and of 10 euros for the zonein which the passenger-compartment calculator has been placed. Let usalso suppose that the quality defects associated with the cablings areidentical and equal to 100 ppm for the two scenarios, but that therepair cost is negligible except for removal. For simplicity, it isassumed that the majority of the cabling under consideration is locatedin a 50-euro zone, just as the air-conditioning calculator. The unitcost for replacement of the calculator is then 100*200/1,000,000, or0.04 euro, to which there must be added 0.01 euro for theair-conditioning calculator and 0.002 euro for the air-conditioningcalculator. The cost of repair of the cabling is 0.01 euro per defectover the entire cabling that is present only when the air-conditioningoption is chosen. Our consolidated unit cost integrating the qualitydefects is therefore now 360+0.4*100*((0.04+0.01) (calculator)+0.01(cabling)) euro, or 362.4 euros, whereas the scenario withpassenger-compartment calculator now costs 350+0.4*100*0.01, or 350.4euros, if there is taken into account the fact that the quality costsassociated with the passenger-compartment calculator are presentidentically in both scenarios and that the cabling specific to theair-conditioning option is installed only when the air-conditioningoption is chosen. Let us note in passing that the number of ppm of thescenario with the air-conditioning calculator is 0.4*(100+100), or 80ppm, whereas the number of ppm of the scenario without theair-conditioning calculator is 0.4*100, or 40 ppm, after subtraction ofthe ppm associated with the passenger-compartment calculator, a valuethat is constant in both scenarios. At the quality level, the scenariowithout air-conditioning calculator is therefore preferable.

If the weight impact is now taken into account and the consolidated costof a load of one kilogram is estimated as 1 euro then, given on the onehand a weight of 300 grams for the air-conditioning calculator and of100 grams for, the routing, to the air-conditioning calculator, ofactuators specific to the air conditioning, and on the other hand anextra weight of 150 grams for the passenger-compartment calculator andof 150 grams for the routing, to the passenger-compartment calculator,of actuators specific to the air conditioning, it is now found that thecost of the scenario with the air-conditioning calculator, again per onehundred units, is 362.4+0.4*100*0.4 (400 grams)*1 (cost per kilogram)euros, or 378.4 euros and 350.4+0.4*100*0.3 (300grams)*1+0.6*100*0.150*1, or 363.3 euros, for the scenario withpassenger-compartment calculator. In passing, it has been seen that thehypothesis with the air-conditioning calculator involved an extra weightof 400 grams, whereas that for mapping the air conditioning onto thepassenger-compartment calculator is 300 grams when the air conditioningis installed. As a weighted mean, the weight of the scenario with theair-conditioning calculator is 0.4 (installation proportion)*0.4(kilograms), or 160 grams, whereas the weight of the option withoutair-conditioning calculator is 0.4 (installation proportion of airconditioning)*1.3 (300 grams)+0.6 (without air conditioning)*0.150(surplus calculator weight), equaling a marginal weight of 129 grams,and it is this last cabling that is optimal as regards weight.

To conclude, it is still necessary to take into account the cost ofexecution of the elementary operations of the air-conditioning servicein each of the scenarios, which cost must be consolidated in the piececost of the calculators. Let us suppose that the elementary operationsof air conditioning necessitate 1 MIPS and that the marginal cost ofMIPS in a processor is entered in a nomogram and that it gives 2 eurosfor 1 MIPS and 10 euros for 20 MIPS and 9.6 euros for 19 MIPS. Let usalso suppose that, independently of the air-conditioning service, thepassenger-compartment calculator reserves 19 MIPS for execution ofelementary operations. Finally, let us adopt the hypothesis of a linearcost of 1 euro per 2 kilobytes of RAM and a linear cost of 4 euros permegabyte of flash memory. Finally, the elementary operations of theair-conditioning service necessitate 2 K of RAM and 100 K of flashmemory. In this case, the consolidated balance per 100 vehicles for thetwo scenarios becomes: 378.4+0.4*100*(2+1+0.1*4) euros, or 514.4 eurosfor the scenario with an air-conditioning calculator, whereas, in thecase in which the code is executed entirely on the passenger-compartmentcalculator, the cost becomes: 363.3+1*100*((10−9.6)+1+0.1*4) euros, or543.3 euros.

In the final analysis, therefore, the unit consolidated cost of thesolution with air-conditioning calculator is 5.14 euros, whereas thecost of the solution without air-conditioning calculator is 5.43 eurosper unit, assuming a series of 100,000 vehicles and an air-conditioninginstallation proportion of 40%.

The system architecture design tool described in the foregoing makes itpossible to achieve a plurality of validations throughout the designprocess. There are distinguished

-   -   functional validation, which consists in verifying that every        datum consumed by an elementary operation must be produced by an        elementary operation independently of the link of the elementary        operations to the different services. This step can be executed        once the functional architecture has filled in the REQ and FUNC        windows, which are accessible via tabs 611 and 612.    -   Functional validation after mapping, which consists in verifying        that every datum consumed by an elementary operation must be        produced by an elementary operation, and, in addition, that a        pathway that may be composed of intermediate networks and nodes        exists between the producer and the consumer. This step can be        executed once mapping of the services has been executed        completely or partly in the MAP window, which is accessible via        tab 613.    -   Functional validation and validation of the electronic messaging        system, which consists in verifying that every datum consumed by        an elementary operation must be produced by an elementary        operation, and, in addition, that a pathway that may be composed        of intermediate networks and nodes exists between the producer        and the consumer, and, in addition, for at least one pathway,        sites in the frames are provided for transporting the datum from        the producer to the consumer. This step can be executed when the        data frames have been executed, partly or completely by means of        the HWD and MSG windows, which are accessible via tabs 615 and        616.    -   Validation of the architecture of the services per configuration        and/or per mode, which consists in applying the three foregoing        validations on the one hand for each configuration of the        product and on the other hand for each transverse mode of the        product.

For example, for a configuration whose only options and choices ofcalculator are air conditioning present or not present and gasoline ordiesel control, the validations must therefore be applied to the fourresultant variants: gasoline with or without air conditioning, anddiesel with or without air conditioning. As regards validation for agiven mode, the configuration being fixed, each type of validation canbe reproduced except for the subset of elementary operations that arepotentially active when the engine is stopped.

These validations are accessible via a user menu (not illustrated),which can be accessed by clicking on Tools tab 606 shown in particularin FIG. 6. In this user menu, it is possible to choose on the one handone of the three validations—functional validation, functionalvalidation after mapping, and functional validation and validation ofthe electronic messaging system—and on the other hand the perimeter tobe adopted for these validations, the subset of calculator variantsand/or of service variants, the mode or set of modes, and/or theconfiguration or set of configurations on which these validations mustbe executed. All of these validations are executed automatically on thebasis of data specified in the system architecture design tool.

Given a use case, a performance constraint is imposed on this use caseas well as on certain of the elementary operations executed in thearrival state of the said use case, and the fact that this performanceconstraint is satisfied is validated for a mapping of differentelementary operations.

As an example, let us take the use case that we will call CRASH: “In anengine running context, if a crash is detected, then the vehicle mustundergo emergency unlocking”. To implement this case, a “crash detected”request is specified. It is executed by an elementary operation thatsenses the value given by an accelerometer “A”. This value is “a”. Theacceleration-sensing software driver corresponds to the program “P1”. Inthis case, the arrival state of the CRASH use case is for example,a-state that we will call “Emergency unlock”. In this state, theelementary operation of “unlock doors” is executed. It corresponds to adatum “d” set to 1, which controls via a software driver P2 thatcontrols door locks V1. If a performance constraint of 100 ms is imposedon execution of the CRASH use case, this means:

that the accelerometer has detected a crash value “a”

that the value of “a” has been refreshed by executing driver P1

that entry into the emergency unlock state has been executed

that datum “d” has been set to 1

that software P2 has been executed

that locks Vi have operated all in less than 100 ms. Some of these stepsare parallel and others are sequential.

If, in addition, the accelerometer is now mapped onto an airbagcalculator and control of the locks is mapped onto another calculator,such as the passenger-compartment calculator, and these two calculatorsare connected by a CAN bus on which datum “a” is transported by a frameT, then the constraint of 100 ms now means:

that the accelerometer has detected a crash value “a”

that the value of “a” has been refreshed by executing driver P1

that the value of “a” has been written into the CAN driver of the airbagcalculator in order to send frame T

that frame T has circulated on the bus

that frame T has been read and the value of “a” has been extracted bythe CAN driver of the passenger-compartment calculator

that entry into the emergency unlock state has been executed

that datum “d” has been set to 1

that software P2 has been executed.

that locks Vi have operated all in less than 100 ms. On the basis ofthis list, performance requirements for execution of each of these stepsmust be established. For example, it may be proposed that frame T besent every 20 ms, leaving 80 ms of execution time for the otheroperations, which are executed sequentially before or after the framehas been sent. If this hypothesis proves too difficult to maintain, thetransmission time of T will be shortened to 10 ms, for example. Incontrast, if it is seen that the network via which T is transported isvery loaded, it will be attempted to impose a requirement that T be sentevery 30 ms and that all operations that must take place before or afterT has been sent be executed in less than 70 ms.

Reciprocally, if performance requirements were imposed on these diverseoperations, it is possible to verify that the sum of these operationsindeed comes to less than 100 ms. Finally, if certain requirements arespecified but not others, the time remaining for execution of all theoperations on which no constraint has been imposed is deduced from thealready specified. requirements.

If a search is made for an anomaly related to execution of the CRASH usecase, it means that priority can be given to searching for the causesamong the different components that execute the CRASH use case, such as:

the accelerometer has detected a crash value “a”

the value of “a” has been refreshed by executing driver P1

entry into the emergency unlock state has been executed

datum “d” has been set to 1

software P2 has been executed

locks Vi have operated

In this way there can be automatically synthesized the list ofelementary operations, of executions of drivers, writes and reads inframes, of taking information into account by sensors and actuators andof frame transfer on a network, and in particular there can be describedall the operations to be effected during execution of a use case, inorder to know exactly in which set of objects to search for the cause ofa defect detected during execution of the CRASH use case.

Once mapping has been executed, the elementary operations that must beoperational can be automatically identified in each transverse mode t.When at least one elementary operation is functioning on a calculator,this means that the calculator must be initialized, even partly, in thecorresponding mode. When no elementary operation is being executed in agiven transverse mode on a calculator, that means that it can bedeactivated.

In contrast to European Patent 0696775 A1, a 2-D topology is not aprerequisite in the present invention. A 2-D topology is a result of themethod of the present invention, and consequently it can be used, forexample, as an input of such systems. Also, according to the presentinvention, the pathways are generated automatically. It is evident thatthe design method and corresponding tool permit “top down” approaches,by following the tabs in order, as explained in the description, as wellas “bottom up” approaches, or in other words by following anyspecification order desired by the designer, including by selecting thetabs in the order inverse to that explained in the description.

It will also be understood that the procedure of the present inventioncan be executed in the form of a computer program and stored in thememory of a computer. It will be possible to produce manufacturedarticles in which it will be possible to store such computer programs.

1-37. (canceled)
 38. A method for designing a specification of ahardware and software system, comprising: defining services and, foreach service, use cases; associating each use case with at least onedeparture state of the system, a user request, and, for each departurestate, an arrival state of the system; defining operations, in thecourse of which, for each state, a set of elementary operationscorresponding to the system response during arrival in the state isdefined; specifying system architecture defining electronic controlunits and networks; mapping elementary operations onto calculators; andexecuting at least one of: identifying data flows circulating on thenetworks as a function of the mapping; and identifying a specificationof the calculator interfaces as a function of the mapping.
 39. A methodaccording to claim 38, wherein the mapping comprises, for each service,a choice among a plurality of mapping modes comprising: mapping theservice onto a single calculator, master-slave mapping, in which asupplementary elementary operation of control of the single serviceactivates, depending on a state of the service in which the system findsitself, elementary operations of the service, the supplementaryelementary operation being mapped onto one of the calculators,distributed mapping, in which the elementary operations are distributedover at least two calculators and, onto each of the calculators, asupplementary elementary operation of control of the service is mappedand activates, depending on the state of the service in which the systemfinds itself, the elementary operations of the service mapped onto thecalculators.
 40. A method according to claim 39, wherein thesupplementary elementary operations are generated automatically with: asinputs, all data necessary for calculation of transitions of a controlautomaton of the service whose states are the states of the service andthe transitions are transformations, via an elementary operation, of theuser's requests, and as an output, a datum representing the state inwhich the service finds itself.
 41. A method according to claim 38,wherein, in the identifying data flows, a state of each data flow isdetermined relative to a given electronic messaging system: free data,to be mapped into frames, data already mapped into frames andcirculating on the network, and such that the data are produced in thecalculators in which the frame is produced and consumed in thecalculators in which the frame is consumed, and unused frame sites. 42.A method according to claim 38, wherein, given a use case, a performanceconstraint is imposed on the use case and on certain of the elementaryoperations executed in the arrival state of the use case, a list ofthose executions of elementary operations, executions of drivers, writesand reads in the frames, taking into account of information by sensorsand actuators, and frame transfer to a network that are implementedfollowing mapping of the elementary operations is then automaticallysynthesized, requirements of delay of execution and/or of response timeof transmission, reading and writing frames, and execution of driversand of elementary operations are then specified, response times ofsensors and actuators are indicated, a fact that a performanceconstraint is satisfied for a mapping of the elementary operations isvalidated or requirements of delay of execution and/or of response timeto satisfy the performance constraint are specified.
 43. A methodaccording to claim 38, wherein if, for a service having at least twovariants, the variants have shared elementary operations, then theelementary operations are automatically mapped onto the same calculatorsor calculator variants during mapping of one of the variants.
 44. Adevice for design of a specification of a hardware and software system,comprising: means for defining services and, for each service, usecases; means for associating each use case with at least one departurestate of the system, a user request, and, for each departure state, anarrival state of the system; means for defining operations, in thecourse of which, for each state, a set of elementary operationscorresponding to the system response during arrival in the state isdefined; means for specifying system architecture defining electroniccontrol units and networks; means for mapping elementary operations ontocalculators; and at least one of: means for identifying data flowscirculating on the networks as a function of the mapping; and means foridentifying a specification of the calculator interfaces as a functionof the mapping.
 45. A device according to claim 44, further comprisingmeans for selecting a hierarchical description, selection of eachselection means causing a different screen of the device to appear. 46.A device according to claim 45, wherein, for at least one screen, thehierarchical description represents, at a first level of hierarchy, aplurality of services and, at a second level of hierarchy, a pluralityof use cases for each service.
 47. A device according to claim 46,wherein, for at least one screen, each use case comprises an initialcontext or situation of the system, a user's request to the system, anda response of the system corresponding to a change of its state.
 48. Adevice according to claim 46, wherein, in at least one screen, statesand associated state transitions are defined for each use case of aservice.
 49. A device according to claim 44, wherein the states thatfunction in modes transverse to common services are grouped in phases,each state is associated with one phase of the system, the set offormalized use cases represent all responses or absences of response ofthe system in all phases, these in total representing all combinationsof modes of operation of a vehicle.
 50. A device according to claim 49,wherein each phase is composed of a set of combinations of modes ofoperation of the vehicle, the modes being transverse to the services andoutside the direct control of the services.
 51. A device according toclaim 45, wherein, for at least one screen, the hierarchical descriptionrepresents a plurality of services at a first level of hierarchy and ofphases of the service at a second level of hierarchy.
 52. A deviceaccording to claim 47, wherein, for at least one screen, thehierarchical description represents a plurality of services at a firstlevel of hierarchy and of states of the service at a second level ofhierarchy.
 53. A device according to claim 51, wherein, within thehierarchical description, a hierarchical level in a given statedescribes the elementary operations.
 54. A device according to claim 45,wherein, for at least one screen, mapping of elementary operations ontocomponents represented in a synthetic view is effected.
 55. A deviceaccording to claim 54, containing, for at least one screen, a syntheticview representing an envelope of a component and each elementaryoperation that the component controls or instructs.
 56. A deviceaccording to claim 45, containing, for at least one screen, a syntheticview representing an envelope of a service and each elementary operationthat the service comprises.
 57. A device according to claim 45, wherein,for at least one screen, at a first level of hierarchy, the hierarchicaldescription represents the calculators of the system and, at a secondlevel of hierarchy, elementary operations electronically monitored orcontrolled by each calculator.
 58. A device according to claim 57,wherein, for each screen, a hierarchical level represents, for eachcalculator, the services that are mapped at least partly onto thecalculator.
 59. A device according to claim 57, wherein, for eachscreen, a synthetic view represents, for each calculator, the modes inwhich the calculator must function.
 60. A device according to claim 45,wherein, for at least one screen, a synthetic view represents at leastone network and the components connected to it.
 61. A device accordingto claim 45, wherein, for at least one screen, at a first level ofhierarchy, the hierarchical description represents the calculators ofthe system and, at a second level of hierarchy, for each calculator, thedata frames are transported on buses to which the calculator and/or theelectronic components directly connected to the calculator areconnected.
 62. A device according to claim 45, wherein, for at least onescreen, the hierarchical description represents the frames at a firstlevel of hierarchy and, at a second level of hierarchy, for each frame,the data contained in the frames.
 63. A device according to claim 45,wherein, for at least one screen, a synthetic view represents componentsand/or networks and a projection of a service onto the components and/ornetworks.
 64. A device according to claim 45, wherein, for at least onescreen, a hierarchical level describes, for each elementary operation,input and output interface data flows, and, for each data flow, a driverand the component and/or the elementary operation with which the dataflow is exchanged.
 65. A device according to claim 45, wherein, for atleast one screen, the hierarchical description represents, at a firstlevel of hierarchy, a plurality of services and, at a second level ofhierarchy, a plurality of service variants, for each service.
 66. Adevice according to claim 45, wherein, for at least one screen, thehierarchical description represents, at a first level of hierarchy, aplurality of electronic components and, at a second level of hierarchy,a plurality of variants of electronic components, for each electroniccomponent.
 67. A device according to claim 45, wherein, for at least onesynthetic view, a selection of an element of the synthetic view by apointing device gives access to a representation of the functioning ofthe element.
 68. A device according to claim 44, wherein, for a usecase, given partial or complete mapping of the services, the set ofelementary operations in the architecture and the set of data exchangedcorresponding to execution of the use case are automatically identified.69. A device according to claim 44, wherein, for a use case, if aperformance constraint is imposed on the use case, the set of elementaryoperations in the architecture, a set of frames exchanged, and a set ofsensors necessary and/or a set of actuators activated are automaticallyidentified, in such a manner as to assign respectively thereto specificconstraints of delay of execution, of delay of transmission, of delay ofactivation, and/or to validate the constraints already imposed.
 70. Adevice according to claim 44, further comprising, for objects, hardwarecomponents and/or services offered to the client, a graphicrepresentation comprising: a contour representing the object,representations of other objects with which the object communicates, andrepresentations of data exchanged with the other objects.
 71. A deviceaccording to claim 70, wherein, when the envelope represents a hardwarecomponent, data representations are effected for a service.
 72. A deviceaccording to claim 44, further comprising, for each bus, arepresentation of components that are connected directly thereto and,for components directly connected to at least two buses, for each ofthese at least two buses, associated with the component, an identifierof each other bus to which the component is directly connected.
 73. Adevice according to claim 72, wherein the identifier is a graphicalelement.
 74. A manufactured article comprising: a computer storage meanshaving a computer program for designing a specification of a hardwareand software system, wherein the program comprises a code for executionof the method defined in claim 38.